From nobody Fri Jun 1 06:43: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 AAB6712D86F for ; Fri, 1 Jun 2018 06:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzgwMEfkvL8v for ; Fri, 1 Jun 2018 06:43:32 -0700 (PDT) Received: from atl4mhob11.registeredsite.com (atl4mhob11.registeredsite.com [209.17.115.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE2112D869 for ; Fri, 1 Jun 2018 06:43:32 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob11.registeredsite.com (8.14.4/8.14.4) with ESMTP id w51DhTx4002660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 1 Jun 2018 09:43:29 -0400 Received: (qmail 19323 invoked by uid 0); 1 Jun 2018 13:43:29 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 1 Jun 2018 13:43:29 -0000 To: Brian E Carpenter , v6ops@ietf.org References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> <73132fdc-13f0-4171-a7fa-275d63f778db@gmail.com> From: Lee Howard Message-ID: Date: Fri, 1 Jun 2018 09:43:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <73132fdc-13f0-4171-a7fa-275d63f778db@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2018 13:43:35 -0000 On 05/31/2018 05:32 PM, Brian E Carpenter wrote: > On 01/06/2018 03:35, Lee Howard wrote: >> I note that the IAB had a measured response: >> >> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t-sg-20-response-to-liaison-1546-attachment-1.pdf >> >> I support that statement. > I'm a little puzzled why this list wasn't informed of this statement > at the time. It didn't occur to me. Suresh informed the list when the SG20 liaison was originally sent. I plead short-timer syndrome, since it was right around my last IETF on the IAB and as WG chair, and I was largely focused on clearing my plate of the thing right in front of me. I also didn't want to represent an IAB statement as an IETF consensus statement, but forwarding the statement to the list would not have created that confusion. I think it is common for liaison statements to be sent to the IETF list, but I don't think it went there. So, I completely own this, I'm the person who should have done it, and I allowed myself to get stuck into tunnel vision and did not think about how the broader IETF community would be interested in what we said. I apologize for that. Lee > >> Bearing in mind that I have no official position, and therefore any >> opinions expressed below are mine only: >> >> The IETF, and any working group in it, has only one way to make a >> statement: an RFC from the IETF stream. No other kind of document >> requires IETF consensus, which is the only way to reflect an IETF >> statement. I am skeptical that we can generate a timely consensus document. >> >> We don't need to say, "Stay out of our sandbox." Turf wars are stupid: >> as engineers, we don't care who does the work, we care about the quality >> of the work. Getting defensive is a sign that we care more about >> protecting some interest than about making the Internet work better. >> >> Comments about the technical problems with the proposed model are >> appropriate. I would include implementation considerations, such as the >> potential for people to think the model is compulsory, or overrides >> other local network considerations. However, I have no reason to believe >> that comments on v6ops or other IETF mailing lists will be received by SG20. > They can be, via our liaison channel. But it seems to be too late now > (see above comment). > > Brian > >> On those bases, RIPE may be a more effective place for discussion. >> >> Lee >> >> >> On 05/30/2018 11:51 PM, Brian E Carpenter wrote: >>> Ignoring the journalistic exaggerations in the article (2nd link below), >>> do we have a liaison comment going to the ITU about this draft? >>> https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf >>> It seems to be an excellent recipe for burning up address space. >>> The due date appears to be now. >>> >>> http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ >>> >>> Regards >>> Brian >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From nobody Fri Jun 1 07:31: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 D94C412D883 for ; Fri, 1 Jun 2018 07:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn1qR-UnVRdH for ; Fri, 1 Jun 2018 07:31:35 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6700D12D880 for ; Fri, 1 Jun 2018 07:31:35 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 14-v6so14637517oie.3 for ; Fri, 01 Jun 2018 07:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SBx5i5FRA+XCt2w5GpTqty+oTW5UrgVeUYNvVcxpJ4Y=; b=hxlDuGz5VtDCqtY9TYZjceqL4p7FCRfQWVSVHinWjkjs5FXKIzzJ8/lcHB6pPwkORq WVlNcw9FWV2O7iu5cMfKbyMeXCK+MZRoYXRtW1NExwYzuOg7sKWlxHAXHl/gXOfPc9So DWg3VoM+UyHGFeLmiZdJkGtdaqR0zB7BWCVXiAhrq0lACGRfMGMIGO0Tw5z1ESnK53vr n+YWCSmX7BaAjyDByEtXWTWA5Rcb/RzLkIBAqKwR+Sge+umWlLSAwvBUI2CHHR2XwH6l iBZ7sZ1bgPB+4iBTD+LbWAApzBdWuNvCnA6jhqfoUu2spuDEq/c3FFLPYFdz55rcPWh1 GoMA== 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=SBx5i5FRA+XCt2w5GpTqty+oTW5UrgVeUYNvVcxpJ4Y=; b=JlCxfK5gQBCd+RHbo+5Dc0/AgDtWl1s+wZG4l0llH9cRhPFk3wdRXuG/vil0E8jehb MNGiV88+IRBHdCB4Ytpi6mxNq1dO1qm2XtuatVcpoRr0hOpOuo058YVX1QgcbvtMMmxG OisbKfBdYnmNMPBKG+v0xivOzqVGvQvYjJJVkCCdzLylVfE4uoVY2pjWdyfxj34R1jtt FVgybBkhoRo7IJD0sA6GIIBlEdnH1vlg5sI3c8ajPZL7a5mksroN5+i3OUCrDy5dKG7S 4LLJpS4iYwZWwqD3nBc4a9rUxbMR7zFsHJrLUPEwMr17smIsY6SqzptWZB9p8nlknft6 PDAw== X-Gm-Message-State: ALKqPwfpeIbbsOzagighSGX55r1QTIn7VQ/ELp1zIOCkmmtG50Ql5r0e 7f7oEVMRq+ZQ6CUQa1W+9YMxj5WM X-Google-Smtp-Source: ADUXVKJCzqlH/w3OzHVu2kEESi1Mh8fP0L4OoYDjEHT/UbD0oumy3GmQK5S4MAQB06Oe4LbhhHfcLg== X-Received: by 2002:aca:ab15:: with SMTP id u21-v6mr3793454oie.272.1527863494540; Fri, 01 Jun 2018 07:31:34 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::10a8? ([2600:8802:5600:1546::10a8]) by smtp.gmail.com with ESMTPSA id a14-v6sm21339218otf.4.2018.06.01.07.31.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 07:31:33 -0700 (PDT) From: Fred Baker Message-Id: <43D8A1F1-3E04-45CB-8D21-0A9DAAC2D3CB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A825DB3C-0FAD-4F48-81CC-8FAB68AB0478"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 1 Jun 2018 07:31:31 -0700 In-Reply-To: <152786246590.15070.12305550744345936078.idtracker@ietfa.amsl.com> To: v6ops list , Lee Howard References: <152786246590.15070.12305550744345936078.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Personnel change for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2018 14:31:37 -0000 --Apple-Mail=_A825DB3C-0FAD-4F48-81CC-8FAB68AB0478 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At IETF 102, we thanked Lee Howard for several years of service as one = of the co-chairs. In this note, I'll thank him again - he's been more = than an asset in our work. But he is moving on; $DAYJOB calls, and he = needs to spend his time there. As of this morning, the Secretariat has = made the relevant changes including the v6ops-chairs mailing list. I = hope he won't go far... Thanks Lee. Fred --Apple-Mail=_A825DB3C-0FAD-4F48-81CC-8FAB68AB0478 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+AFAlsRWMMACgkQEhdRnd2G P+CtaQ//RLfds0ShqNLe8LBn670NOIpuPTp/MMc+1WsmUmzPLxNnLlN+N3mSCXXa sFJoRhWBEU4tzwyOIDEsa9+T07m6HOSechOBchM6/wSH2vIN5pQ35xOux7I02OP2 uvLoxkvudrP6GE4CFIVXsNCrfsQ5q09ee/gpg8k0acS/dKKdD+ACN+m9+zkbMd8w Y8DmP53pnkOCgIqmlZH52SSmF8e3hUkkiuM7mJueUkciyREJRubMXlJWpxH5OEEX tImeZQFu6/9MMQCkiiSv9gHSgZVDixE3CZyLvJYqi4C1uiJ2wiV8I33loTeDkeE4 eMvfwIk+OLrxOrtBDuUD5IFzd+1s4kecgOfgrvUH+Kx1Sk+b9OoEMjhYYbgfA6mk UCvyxqDk8c70dNznzdoGQ8Ju+lQ7/Wj7KBunFtN0ucbQbu0FIel2k+xC+sxjk4VH 5ESTg0KUEg4jpkIqRNl+Dq0nMlbuG5mXLQ0SxdQbMkpkDM2NA33c3C8uYvzoWI33 yo0cTl5EyI5qWoqLTnUhLUMnHJ/3kYHfz2gVhiqU6PT0jJmGGUVc+P4z9C44lfCq L5x5sURhxdu3JQ+rb+T4nL08+Vjh97vA9VHBH4p3xDlMTqTO48+3/5yFgoMeYApe Htjp+1r3pl8HLjwwbp7IIlhD6LsY5ZthGchZiJuNdXSUqHW0ceE= =ulu0 -----END PGP SIGNATURE----- --Apple-Mail=_A825DB3C-0FAD-4F48-81CC-8FAB68AB0478-- From nobody Fri Jun 1 07:47: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 3860B12D883 for ; Fri, 1 Jun 2018 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.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 YVe8td341JfD for ; Fri, 1 Jun 2018 07:47:26 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105A412D880 for ; Fri, 1 Jun 2018 07:47:25 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 4B0A41C1262 for ; Fri, 1 Jun 2018 09:47:25 -0500 (CDT) Received: from imsva2.bcbsm.com (inetmta04.bcbsm.com [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 69CA41C113E; Fri, 1 Jun 2018 09:47:24 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 37DCCFE05C; Fri, 1 Jun 2018 10:47:24 -0400 (EDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0BC17FE054; Fri, 1 Jun 2018 10:47:24 -0400 (EDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (unknown [207.46.163.113]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 1 Jun 2018 10:47:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b3oT/ci5fQfOW61PPzKr5zg0VlOdMnIdTMEMqtgeTTY=; b=kneuc2kpjUSEdhZ4pbTo3DGjfVyu6oz6nMyf1z/cGVMhBAKAobnFyYRboRK7dn4nlfKIrraDeLzmgaSLVfrjBZfhw5zMRBTBZvuvr+yq22vtNJePHsFfS00APKvpSuvlyTE5G7q6aTSDIUUQgHnacnZuTVhGoTwRKHS/2Pxsqss= Received: from BN7PR14MB2369.namprd14.prod.outlook.com (20.176.22.144) by BN7PR14MB2305.namprd14.prod.outlook.com (20.176.22.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Fri, 1 Jun 2018 14:47:22 +0000 Received: from BN7PR14MB2369.namprd14.prod.outlook.com ([fe80::e5d7:9d7:9ca9:c570]) by BN7PR14MB2369.namprd14.prod.outlook.com ([fe80::e5d7:9d7:9ca9:c570%2]) with mapi id 15.20.0820.012; Fri, 1 Jun 2018 14:47:22 +0000 From: "Ackermann, Michael" To: Fred Baker , v6ops list , "Lee Howard" Thread-Topic: [v6ops] Personnel change for v6ops WG Thread-Index: AQHT+bVO/upYFJsILUKNn7BeU8S0g6RLezvQ Date: Fri, 1 Jun 2018 14:47:22 +0000 Message-ID: References: <152786246590.15070.12305550744345936078.idtracker@ietfa.amsl.com> <43D8A1F1-3E04-45CB-8D21-0A9DAAC2D3CB@gmail.com> In-Reply-To: <43D8A1F1-3E04-45CB-8D21-0A9DAAC2D3CB@gmail.com> 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=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2305; 7:BKug9YvU2ozwYSFiJaBMKHKy9gWxN3+rR0Y6HKdgBB6UPPEdlR3caIg83cuO808dIrIctxV6prLIKRuULOBjdKyGGmLGJXG2cB5/k2vVrnZ3y9UtjLV9gTJHZyGlR40tz3nG7vOPfvVV0jeqIdwsO7juA9XqwK5457nSO89bM/92+pgaHL+9A77Rjtze01Nvj6aYMKSLp+M4RwmXyZ9MEqmljyA4tXuUe3jg/VY4NoQeET1iJwvCXHnIBtMX8hIO; 20:QRjKrtI6mWHB8QH0VkiaHnJtSV1znjuKtWJduWY4PguQ5rBQXTT0916qXiuGdqYjyBX+vfFK0duAETtlCEeZVlzUXHMF8wMPzPjV0KDBJq4mQoIEynUKnV+l4uOoeDcMIA3TIqR3jc5AgqIiiK7N319HhX7YE+dh7z9nyhs79bE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7167020)(7153060)(7193020); SRVR:BN7PR14MB2305; x-ms-traffictypediagnostic: BN7PR14MB2305: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2305; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2305; x-forefront-prvs: 0690E5FF22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(376002)(366004)(39860400002)(199004)(189003)(13464003)(43544003)(55016002)(229853002)(186003)(14454004)(5250100002)(3846002)(33656002)(53546011)(6246003)(6506007)(6116002)(39060400002)(6436002)(81156014)(8936002)(86362001)(72206003)(26005)(478600001)(3280700002)(2906002)(81166006)(8676002)(3660700001)(7736002)(11346002)(53936002)(76176011)(25786009)(446003)(110136005)(102836004)(476003)(74316002)(316002)(305945005)(5660300001)(486006)(66066001)(55236004)(2900100001)(106356001)(105586002)(9686003)(97736004)(7696005)(80792005)(99286004)(68736007)(32563001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR14MB2305; H:BN7PR14MB2369.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VkO+63Fekwuja0NzFMJzcqR/N5A0VfyVP/wW5Rq1HY00VyOdflCDPPXob1sC6IyajIxxx5/15rOCTVHInzq9Mcod/47wsEZe4QcuawJwkvmMDTxndlPvrLCBzjJ5YBIu6gvwH2Pt9M2PqS9TjpivDiits73aTNJ3cmWKPwTH6De2mzzO8jZPc0Fa9tMx5JsN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1adfe95d-6e02-42a4-f3f1-08d5c7ce9587 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1adfe95d-6e02-42a4-f3f1-08d5c7ce9587 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2018 14:47:22.7761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2305 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 9c47664e-d4fe-43f6-87e7-35cde98c5cb9 X-VPM-MSG-ID: 1ac71b6f-6e0c-4834-8fbe-4a1d09f44d91 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] Personnel change for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2018 14:47:28 -0000 Thanks from all of us Lee. =20 You have been great in SO many ways=21 Hopefully you will stay involved in some capacity=21 Take care Mike -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Fred Baker Sent: Friday, June 1, 2018 10:32 AM To: v6ops list ; Lee Howard Subject: =5Bv6ops=5D Personnel change for v6ops WG At IETF 102, we thanked Lee Howard for several years of service as one of = the co-chairs. In this note, I'll thank him again - he's been more than an = asset in our work. But he is moving on; =24DAYJOB calls, and he needs to = spend his time there. As of this morning, the Secretariat has made the = relevant changes including the v6ops-chairs mailing list. I hope he won't = go far... Thanks Lee. Fred The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Fri Jun 1 08:00: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 438A512D890 for ; Fri, 1 Jun 2018 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd-KybBfBays for ; Fri, 1 Jun 2018 08:00:52 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 E4E1E12D88A for ; Fri, 1 Jun 2018 08:00:51 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 15-v6so29578791otn.12 for ; Fri, 01 Jun 2018 08:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=FvvGHC7uvC/0cokI816JvK7tEqGTynjqZmtJSu3CHSg=; b=nJmg74+HrPFL+X9Sv0Vrs92Mzrrx7h7yjv4rd1ocUSAQSm93a+c6CN6k0q9KNF5k3E 1SpLxauNN6nguYwrO/5fqiKwAUO3mrIZKfn9GzaF4LpUYh2HZTKiwB+D8vNg7si/klbZ YcxN3toYGOak8q6ayAff8YZlFfrGg62d+DX0oE74RmEXoldrgs+8Enytg3NSRmCMrOn+ 2BlsKld0OeVSTAwgqW9FJRdX0DnOaq0mU/lGOijM9lleQN0fDIR1+FYVSl34yFh/kX5e 8i3PJaKi19ZW6Ihoq/1uR9HXU9LvLuc9kflqvICLCNOYzsC5NxC7tr/FzhxdRiu66Vvx WBng== 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:message-id:to; bh=FvvGHC7uvC/0cokI816JvK7tEqGTynjqZmtJSu3CHSg=; b=bW0PdeVLuPn102/8Gk0b3vSt/di0/frEKIL/zsRRAfbZkZDo0RyXUIcrHDd8U/rk0W PO20wQ9O6x6NZLaKbQSBdGcJmkMxWlt/2O8UuLBFNyrNnfIUQf3M4G+KKmX4q63drg64 fhzOeiqJto3ELpWwAhrwJU3LYPDL7++zxaU0DLrHFIbvQt8dfjEDB8nRTvKe1Ye8RpM3 +vqkXSjrGS9GnVuKnIawPMzPF9StZ51qv0rNGbzpHkUkI/W9v8j1BbEJTDQn1fxhFSWN 4j5GAQVCN5DqdHCxqsnW13sYzw9WNBmGyOo19yPypantY+4JTScL5BpQ6widXlEvctXx ftAA== X-Gm-Message-State: ALKqPwcA0fdTXQiGMoOwV+K4fX0GWt0VC8rOR0Dl25mYhgugB7Nf8OBv 19muYCjL9J479HK6BCn7Iga8m1Y+ X-Google-Smtp-Source: ADUXVKL5ua7l5YrcuKDH1cJYqF5UqVzH0H+j3GNeWjFRVkDuObhYmwG94M8inrHHBZRWV3IS0NDiKA== X-Received: by 2002:a9d:255d:: with SMTP id j29-v6mr7185935otd.280.1527865251075; Fri, 01 Jun 2018 08:00:51 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::10a8? ([2600:8802:5600:1546::10a8]) by smtp.gmail.com with ESMTPSA id l51-v6sm27106836otb.13.2018.06.01.08.00.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 08:00:49 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_78F98F35-2A8D-4CEC-8641-760E01E24E6F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 1 Jun 2018 08:00:37 -0700 Message-Id: To: v6ops list X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Time to get your drafts in X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2018 15:00:54 -0000 --Apple-Mail=_78F98F35-2A8D-4CEC-8641-760E01E24E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft cut-off for IETF 102 is July 2 at 23:59 UTC. Getting on the = agenda calls for list discussion before the event. That argues for you = getting your drafts in *now*, and then asking the list to comment on = your draft. --Apple-Mail=_78F98F35-2A8D-4CEC-8641-760E01E24E6F 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+AFAlsRX5gACgkQEhdRnd2G P+DeuA//UyOGadKkHrrHcU2eZpQtyzDK+4bjSOn/x+jdv/+zd82GOCtV2Iw/Gxc6 Pzk6PyTOmgB0R4ro1UA2cuWg/TGxqLUsGRyR3EvLIzccBfvm29Z3u+ezKHT+jgbU +0Y4wqJPRxhBB9y0FliAhEKeI4swcogxZ9B35/r5IUBoBQNImGOOURQqgaOey4bh B+nxNd46513aScZ+QdEBdycYxYV0WB6tW5onCHIvAD/aI8KoPiy0JU074hx2MhL/ iDhUuBskGnN5nHdm9CDIWS+vJE5OWi0/PSN7IUYdBXlOvOC/kfyyvWeDEv9DwdZ5 kXGapqWW3tMsLWWmbZumiJjAsyb3QMHAtI83WX5EFdOKxgyj/2sug2x2YpSkDUoN 5DThYzq0iWBW+InjaCInKrnOpnANA2jzg1f9MFLz1idrIYVcKhb+F7woauONh6Oq 6nH1uDHqxUlZD5P6zY6/oOMvFDlTCDmnibUiUmiF2XAjTQXqmqkpyP2BQJJ0URPc x00KK9UuWgdnmooPuU5bNnWICbHX0uMCoGp/jx04XKhrkMlib9ClRjBE2L3N3+nJ hFVT8zNzj3dAYARi1MvCXVwa0xJE9Ug6995hoaaMZ149HFP1QqXUwxq2nljBYVU3 /57rqwBXZVbUUKBx+r1s/ODgaS/B8KeyWcrQxbxHMSXsYS7CS38= =Yj5r -----END PGP SIGNATURE----- --Apple-Mail=_78F98F35-2A8D-4CEC-8641-760E01E24E6F-- From nobody Fri Jun 1 08:07: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 18B2B12D893 for ; Fri, 1 Jun 2018 08:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC8Ecync2h8x for ; Fri, 1 Jun 2018 08:07:47 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF27712D88A for ; Fri, 1 Jun 2018 08:07:47 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id t133-v6so19158700oif.10 for ; Fri, 01 Jun 2018 08:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fgepcEQ1WbIs/46sg2fDX01RPUpgXQlQitO0SnoOHHY=; b=cO82LLwnLmqLQUjV6qtYL0Eo1bGsRAVE2c02F3S0zISGK+E5aQeUfVuOzhgG9uA8cH 4nnMflh757/98vr//FiVOErfZ+fEhtHf+W1NX8e4jAR8Zd60rEe7istEPj4tVps3w4Dp KzurpyOKjDSCCc07nL+YVOaA5l0pxL200VdAIXcKRto7VF2wglceW6d0BpKxEMRsN6QX 7JllQgXWMRHVMM4HEZvhoi1jYHpR8GxQrOunjLbQpoEtzt6jxFRS4ACZB7+tX0o2/jAK lzVQ62M3bIp1ZzmR1rsjpk/lBzND5TZEzAqMPPlI+AiqXky8X/2OVVaK2B3LhD9yxOe9 6Now== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=fgepcEQ1WbIs/46sg2fDX01RPUpgXQlQitO0SnoOHHY=; b=UIGzH5a9YUFjBm0t+adVjzEDz8TwfjnX4y7tOlp4rJQIrAK/sQBXCI3Nu5YszaXNwd GXDLYd7QH8ZFnkEJ8hb9EEhKAU4cOKqFq+yDLPW4bUQagy4jDpuayUon7bcj820Zacjt zMMKZy9dJPzS6QlOUcUhOLsXxdAADk/HaVoorZn62lNcpAr497OEc8OPOtOp3yN8fwpQ HwoJZlvQwuCoz7IdbP6NtMkcSpDlO0KDxmAedkGEFecwO/wWK3FjGa1rqcqYz8/VmbhX S2ROtNuUXr8Qu7ykA/KMnizXXaE7hJPThzzuFRF2yl+EV9cRz39g8BxOyzjZPVCfe+8l 9/Xw== X-Gm-Message-State: APt69E1noDvoDshBhaATYJk06+JDqu18kXC7ZsKd9Oi615V38BXsqX1l r14VdqpQA0XFGr2xEjOYEPlEDUu7aH08gWbrab1Pbg== X-Google-Smtp-Source: ADUXVKLXeIr3hwrdDLKm6DDMV55R2FhCGCZpJG1wd69nycdnzPjPOrJFJWdeMWtuCgB9I0hBDuU4VZwWFGa+u7/q6Hg= X-Received: by 2002:aca:df41:: with SMTP id w62-v6mr2885483oig.129.1527865667045; Fri, 01 Jun 2018 08:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:403:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 08:07:46 -0700 (PDT) In-Reply-To: References: <152786246590.15070.12305550744345936078.idtracker@ietfa.amsl.com> <43D8A1F1-3E04-45CB-8D21-0A9DAAC2D3CB@gmail.com> From: nalini elkins Date: Fri, 1 Jun 2018 08:07:46 -0700 Message-ID: To: "Ackermann, Michael" Cc: Fred Baker , v6ops list , Lee Howard Content-Type: multipart/alternative; boundary="000000000000596579056d95f2ea" Archived-At: Subject: Re: [v6ops] Personnel change for v6ops WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2018 15:07:50 -0000 --000000000000596579056d95f2ea Content-Type: text/plain; charset="UTF-8" +1 Nalini On Fri, Jun 1, 2018 at 7:47 AM, Ackermann, Michael wrote: > Thanks from all of us Lee. > You have been great in SO many ways! > > Hopefully you will stay involved in some capacity! > > Take care > > Mike > > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Friday, June 1, 2018 10:32 AM > To: v6ops list ; Lee Howard > Subject: [v6ops] Personnel change for v6ops WG > > At IETF 102, we thanked Lee Howard for several years of service as one of > the co-chairs. In this note, I'll thank him again - he's been more than an > asset in our work. But he is moving on; $DAYJOB calls, and he needs to > spend his time there. As of this morning, the Secretariat has made the > relevant changes including the v6ops-chairs mailing list. I hope he won't > go far... > > Thanks Lee. > > Fred > > > The information contained in this communication is highly confidential and > is intended solely for the use of the individual(s) to whom this > communication is directed. If you are not the intended recipient, you are > hereby notified that any viewing, copying, disclosure or distribution of > this information is prohibited. Please notify the sender, by electronic > mail or telephone, of any unintended receipt and delete the original > message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and Blue > Shield Association. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000596579056d95f2ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Nalini

On Fri, Jun 1, 2018 at 7:47 AM, Ack= ermann, Michael <MAckermann@bcbsm.com> wrote:
Thanks from all of us Lee.=C2=A0 =C2=A0
You have been great in SO many ways!

Hopefully you will stay involved in some capacity!

Take care

Mike



-----Original Message-----
From: v6ops [mailto:v6ops-bounces= @ietf.org] On Behalf Of Fred Baker
Sent: Friday, June 1, 2018 10:32 AM
To: v6ops list <v6ops@ietf.org>= ; Lee Howard <lee@asgard.org> Subject: [v6ops] Personnel change for v6ops WG

At IETF 102, we thanked Lee Howard for several years of service as one of t= he co-chairs. In this note, I'll thank him again - he's been more t= han an asset in our work. But he is moving on; $DAYJOB calls, and he needs = to spend his time there. As of this morning, the Secretariat has made the r= elevant changes including the v6ops-chairs mailing list. I hope he won'= t go far...

Thanks Lee.

Fred


The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this communicat= ion is directed. If you are not the intended recipient, you are hereby noti= fied that any viewing, copying, disclosure or distribution of this informat= ion is prohibited. Please notify the sender, by electronic mail or telephon= e, of any unintended receipt and delete the original message without making= any copies.

=C2=A0Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

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



--
Thanks,
Nalini Elkins
Pr= esident
Enterprise Data Center Operato= rs

--000000000000596579056d95f2ea-- From nobody Fri Jun 1 20:13: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 3C085124E15 for ; Fri, 1 Jun 2018 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7rKMni3mDuvZ for ; Fri, 1 Jun 2018 20:13:48 -0700 (PDT) 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 6594A124D68 for ; Fri, 1 Jun 2018 20:13:47 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id i5-v6so16358521plt.2 for ; Fri, 01 Jun 2018 20:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=OlK5N9JKr7Sc57f/q1X/ip0ucYmS+oGrVBnHPd/XcaE=; b=dZRL99UTx4y8li7+eJ8fz75fMZxPMcbbugrIhLU7LhHNMR5GOhQCRVeEZtZ8x3+JoB TJvCwA3WHJrJ2bKi+NC49mJTzg4TcOjH9ryV7znRL/aSAS7mrKYjXJAq13J7lLrjNGA8 Hk0RnBWemKXegD24J/+gc38tH2q6I+fEuLpO3SVzolekskLwqLM/XLmccF/iyfLVPBGg SaS2Y2YrOhJXVN4ccGsoL7nPUAXV9wInKyQLV1y60LsZ6RJaXnU0pd4dFghLObYfEAoD /+UrmpYyQi9MjIHKfmSzZqhQPYIvc4ZQfRVPyDAHLTNRXPSZzgSgqT5ltdPVm3opM/uO QHcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OlK5N9JKr7Sc57f/q1X/ip0ucYmS+oGrVBnHPd/XcaE=; b=Sndu5eYZAyAQeLwJhyiyzodxYkFTgBWrfP7bhIRvqnuTIcL7aoVxOuBS/EH9rrTe8g b6Chw4s44DRBP1/aibbUazKf4BQKXHLyBn0SLGLMuaw4VIS4AiZFDi/EMs6j4QgKI/Fx gW9S9BpxeksfDb4YkLcl4fXm9rMfZKoTko0oM+cxykI85sAWFrArakmZjutByfkYIgXB kyZAzTSp71spIX3ap41hMM+YIJxIquTyzn910ogXLhZRyPyR4eHlB1qjZfAM/agzoJ/d arMpJe0+QsohfqVGmGag1a/+RbnaQ+ihrMt8p42uNUQwdzxtigK2nJe348GeYLL78T3i fVRA== X-Gm-Message-State: ALKqPwezY9zoNBotciocfaZUL6MTaiq3H6Se/9XEtwdTL8n1ElnKYroU 76RCoLZWMY/aWsfJTNn8JFOVQg== X-Google-Smtp-Source: ADUXVKK5cS4Z1KtpUysh92SiM4oe0Z7Oc2KnxMnvjFDz8G+J85hZvcSDKy9hhBuXggmYc0RkSbOgvw== X-Received: by 2002:a17:902:8f93:: with SMTP id z19-v6mr13331881plo.166.1527909226559; Fri, 01 Jun 2018 20:13:46 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id v36-v6sm7074334pgn.34.2018.06.01.20.13.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 20:13:45 -0700 (PDT) To: Lee Howard , v6ops@ietf.org References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> <73132fdc-13f0-4171-a7fa-275d63f778db@gmail.com> From: Brian E Carpenter Message-ID: <33f8bb50-dbb0-7dfa-6b42-22d457de39a8@gmail.com> Date: Sat, 2 Jun 2018 15:13:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Jun 2018 03:13:51 -0000 On 02/06/2018 01:43, Lee Howard wrote: > > > On 05/31/2018 05:32 PM, Brian E Carpenter wrote: >> On 01/06/2018 03:35, Lee Howard wrote: >>> I note that the IAB had a measured response: >>> >>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t-sg-20-response-to-liaison-1546-attachment-1.pdf >>> >>> I support that statement. >> I'm a little puzzled why this list wasn't informed of this statement >> at the time. > > It didn't occur to me. Suresh informed the list when the SG20 liaison > was originally sent. > I plead short-timer syndrome, since it was right around my last IETF on > the IAB and as WG chair, and I was largely focused on clearing my plate > of the thing right in front of me. I also didn't want to represent an > IAB statement as an IETF consensus statement, but forwarding the > statement to the list would not have created that confusion. > > I think it is common for liaison statements to be sent to the IETF list, > but I don't think it went there. > > So, I completely own this, I'm the person who should have done it, and I > allowed myself to get stuck into tunnel vision and did not think about > how the broader IETF community would be interested in what we said. > > I apologize for that. No, please don't, but thanks for explaining. I think the RIPE people have done a good job on technical feedback, anyway. Brian > > Lee > >> >>> Bearing in mind that I have no official position, and therefore any >>> opinions expressed below are mine only: >>> >>> The IETF, and any working group in it, has only one way to make a >>> statement: an RFC from the IETF stream. No other kind of document >>> requires IETF consensus, which is the only way to reflect an IETF >>> statement. I am skeptical that we can generate a timely consensus document. >>> >>> We don't need to say, "Stay out of our sandbox." Turf wars are stupid: >>> as engineers, we don't care who does the work, we care about the quality >>> of the work. Getting defensive is a sign that we care more about >>> protecting some interest than about making the Internet work better. >>> >>> Comments about the technical problems with the proposed model are >>> appropriate. I would include implementation considerations, such as the >>> potential for people to think the model is compulsory, or overrides >>> other local network considerations. However, I have no reason to believe >>> that comments on v6ops or other IETF mailing lists will be received by SG20. >> They can be, via our liaison channel. But it seems to be too late now >> (see above comment). >> >> Brian >> >>> On those bases, RIPE may be a more effective place for discussion. >>> >>> Lee >>> >>> >>> On 05/30/2018 11:51 PM, Brian E Carpenter wrote: >>>> Ignoring the journalistic exaggerations in the article (2nd link below), >>>> do we have a liaison comment going to the ITU about this draft? >>>> https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf >>>> It seems to be an excellent recipe for burning up address space. >>>> The due date appears to be now. >>>> >>>> http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ >>>> >>>> Regards >>>> Brian >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > From nobody Mon Jun 4 18:16:09 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 2DD14130E41 for ; Mon, 4 Jun 2018 18:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy5_XZ3yxpEd for ; Mon, 4 Jun 2018 18:16:04 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA93130E29 for ; Mon, 4 Jun 2018 18:16:04 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id v135-v6so825714lfa.9 for ; Mon, 04 Jun 2018 18:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gF5dpGkRYeTxn65GrEunp6UTBnyVv9rFOIFMVZeyHHc=; b=fYoBbKByNZC2n20N+BLbNowur/Pl1wstHH57w3I18iBXwDB+/Lbgei1pic4SKVgl+9 a9ArGnpARTTUNviJen/RHO9mpK5VamhMcA2zv8lHIToGL0RQxtB2O7VCDmH/U/bTE+m5 FY4InDUV2WUmWH+KXcVls8+5HHrt6ysFLyDJda+dKOgZ2nBrCnnH4T5/TpNYp2l2ZusF QUQq2kKhTfHJ+fdAE3w8s5D9MwNmpmsIz/JxLmZW+EeOx6hEqQ1CRXrukA5gjw9nwKKh k58Uq39f+jRIl5G2zgAV9jTW3guTjZBAuO9tDCQMw3zlfAOPsrbz58LGb6zSHv2eqgnX GG4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=gF5dpGkRYeTxn65GrEunp6UTBnyVv9rFOIFMVZeyHHc=; b=Hp9CNxXCqGXrXi0rx2MZdJxcifWsPW/UY7xHtnhqVqxClUIRcEVh9lz6xpzB4ZVbpT tA0AUF166/W578cH89sGYpgEjUQ/LhQg1S/quCPXgEHWU+cEqUCmvNRv/HWAtPeTclY6 oDG/eTmtBHX/gIcZOyJn9DWzM/pzrwgKG5VpfwPN4Ug0cMmtACWlHwhAs8FH7B/21WIs mAn12PytFtveJcuMmY2EENUbYllE+kCqCCLMINPdSQx9Z5erXuUGkG1HqjbU7uCs9Ibz eW00M8b4KyTDDcSOvuK63LwcNoed5sCxbz2yhq4enEbgHSS3/r084D1kA3ZmXrVH2Ssi SBEw== X-Gm-Message-State: APt69E2o6A2ubFYt09n2JCVT6VrjViF4ySWeMZAR5OTVL21ttn9i2EJH yeJZEjmzGPDNvp/uBsQfzjL4yzjfc2IXIlbbLss= X-Google-Smtp-Source: ADUXVKKAGA6KtagaJtUyRChteNeNHS5vWSVtkzitspfp9OxVUDYDXbeWjjhC+hO13NmZmVPCVLocS6NrOO8a/lKQ9lQ= X-Received: by 2002:a19:ef11:: with SMTP id n17-v6mr283730lfh.66.1528161362333; Mon, 04 Jun 2018 18:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1dd0:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 18:15:41 -0700 (PDT) In-Reply-To: References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> <73132fdc-13f0-4171-a7fa-275d63f778db@gmail.com> From: Jen Linkova Date: Tue, 5 Jun 2018 11:15:41 +1000 Message-ID: To: Lee Howard Cc: Brian E Carpenter , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 01:16:08 -0000 On Fri, Jun 1, 2018 at 11:43 PM, Lee Howard wrote: >>> I note that the IAB had a measured response: >>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t-sg-20-response-to-liaison-1546-attachment-1.pdf >> I'm a little puzzled why this list wasn't informed of this statement >> at the time. > It didn't occur to me. Suresh informed the list when the SG20 liaison was > originally sent. > I plead short-timer syndrome, since it was right around my last IETF on the > IAB and as WG chair, and I was largely focused on clearing my plate of the > thing right in front of me. I also didn't want to represent an IAB statement > as an IETF consensus statement, but forwarding the statement to the list > would not have created that confusion. > > I think it is common for liaison statements to be sent to the IETF list, but > I don't think it went there. > > So, I completely own this, I'm the person who should have done it, and I > allowed myself to get stuck into tunnel vision and did not think about how > the broader IETF community would be interested in what we said. [RIPE IPv6 WG co-chair hat on] it's not your fault - I missed it as well. I knew about the IAB response and I *was told* the proposal was sent to the WG. So I *assumed* it was (as I'm constantly behind my mailing list subscriptions) and I did not verify it was discussed here. Anyway the RIPE WG was very consistent in their feedback (and discussion continued in the mailing list after the meeting, https://www.ripe.net/ripe/mail/archives/ipv6-wg/2018-May/thread.html) -- SY, Jen Linkova aka Furry From nobody Tue Jun 5 06:20: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 073E913100F; Tue, 5 Jun 2018 06:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KNSr2TzSwFY7; Tue, 5 Jun 2018 06:19:58 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB27113100D; Tue, 5 Jun 2018 06:19:57 -0700 (PDT) X-AuditID: d9a9790a-1c1ff700000010b3-5e-5b168dfb8d76 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id 6B.5D.04275.BFD861B5; Tue, 5 Jun 2018 15:19:55 +0200 (CEST) From: Fioccola Giuseppe To: "v6ops@ietf.org" CC: "Fred Baker (fredbaker.ietf@gmail.com)" , "Bob Hinden (bob.hinden@gmail.com)" , =?utf-8?B?T2xlIFRyw7hhbiAob3Ryb2FuQGVtcGxveWVlcy5vcmcp?= , "Roberta Maglione (robmgl) (robmgl@cisco.com)" , "'draft-fioccola-v6ops-ipv6-alt-mark@ietf.org'" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "v6ops-chairs@ietf.org" , "Suresh Krishnan (suresh@kaloom.com)" Thread-Topic: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-01.txt Thread-Index: AQHT/Mq4gvowBCH8aEGuHK9gYxuzyKRRpWzw Date: Tue, 5 Jun 2018 13:19:54 +0000 Message-ID: <012856c6f7ea40f88e5bddbbbb110520@TELMBXB02RM001.telecomitalia.local> References: <152820257094.18010.12115397077426983981.idtracker@ietfa.amsl.com> In-Reply-To: <152820257094.18010.12115397077426983981.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.249] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAKsWRmVeSWpSXmKPExsXCxfdHSvd3r1i0wc1Jqha7p0xjs9j6fh+b xbFpjcwWt782sFpMblvBZrG2x8piW9cpFoupj98zWZw+tpfZgdNjyu+NrB4Hj31k9Ng56y67 x5IlP5k8zl+ZwR7AGtXAaJOYl5dfkliSqpCSWpxsq+SSWZyck5iZm1qkEJKak5qcn6ukkJli q2SspFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V 7AJLU4tL8hVyU4uLE9PTM/MVUhPWC2bc+XefveCbVMWTeRvYGxjnSHUxcnJICJhIvDwyi6WL kYtDSGAqk8SpLb+YQBJsAjYSB1+dYAOxRQRUJU4/vcwMUsQsMI9FYnrLPRaQhLBAqMS2x5NZ IIrCJLZtfMkMYRtJTLlyCsjm4GARUJE4NaUeJMwrECgx9fILsHIhAT+JBZNfsoPYnAL+EuvO vGYEsRkFZCUm7F4EZjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsA0kti7dxwJhK0r87vzD BmHLSCw8MpkV5ARmAU2J9bv0IUYqSkzpfsgOcY6gxMmZT1gmMIrNQrJtFkLHLCQds5B0LGBk WcUomlthYKhXAom9zJLEnMxEvcySTYzAZHRzZSXXDsbXq5wPMQpwMCrx8MbViUULsSaWFVfm HmKU4GBWEuHlcQcK8aYkVlalFuXHF5XmpBYfYvQBBtdEZinR5HxgoswriTc0sbA0NLawMDK0 MDPFIawkzvvMFGiWQDoweWWnphakFsGMY+LglGpgdNyh/e3w77M/Fs+5mJAnOEV90rKIZcIu 0xKuuHyZseiFUlSxw2Gbj5vlFjO7F9+5fIBpt9Gc5wIr3ujvn3Ix+UF887u+Q9FfD4btPqwQ I3wj+26TU1DBkzJN1r3zOgzC175WL9Rk3JQ2cRbLAsObs3cm1Gb9DJJh+8U/59nj3ukT11b9 9267o63EUpyRaKjFXFScCADucTpMcwMAAA== Archived-At: Subject: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 13:20:02 -0000 KEknbSByZXNlbmRpbmcgdGhpcyBlbWFpbCBpbiBjYXNlIHlvdSBoYXZlbid0IHJlY2VpdmVk IGl0LikNCg0KSGkgQWxsLA0KWW91IG1heSByZWNhbGwgdGhlIHByZXNlbnRhdGlvbiBvZiBk cmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrIGluIGJvdGggNk1BTiBXRyBhbmQg VjZPUFMgV0cuDQpUaGlzIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgYWRkcmVzc2VzIHRo ZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIExvbmRvbiBtZWV0aW5nIGFuZCB0aGUg ZGlzY3Vzc2lvbiB3ZSBoYWQgd2l0aCBGcmVkIEJha2VyLCBCb2IgSGluZGVuLCBPbGUgVHJv YW4gYW5kIFJvYmVydGEgTWFnbGlvbmUuIA0KVGhlIGNvbnNlbnN1cyB3YXMgdG8gY29uc2lk ZXIgdGhlIENvbmV4IGV4dGVuc2lvbiBpbiBSRkM3ODM3IGFzIHRoZSBwcmVmZXJyZWQgb3B0 aW9uIGFuZCB0byBwcm9wb3NlIHRoZSB1c2Ugb2YgMiBiaXRzIGZyb20gdGhlIHJlc2VydmVk IGZpZWxkIGluIHRoZSBSRkM3ODM3IENvbkV4IGV4dGVuc2lvbiB0byBlbmNvZGUgdGhlIG1h cmtpbmcgbWV0aG9kLCBmdXJ0aGVybW9yZSBpdCB3aWxsIGJlIHVzZWQgYXMgSEJIIEhlYWRl ci4NCg0KV291bGQgYXBwcmVjaWF0ZSBhZGRpdGlvbmFsIGNvbW1lbnRzLg0KDQpCZXN0IFJl Z2FyZHMsDQoNCkdpdXNlcHBlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogbWFydGVkw6wgNSBnaXVnbm8gMjAxOCAxNDo0Mw0KVG86IEZpb2Nj b2xhIEdpdXNlcHBlIDxnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0PjsgR3Vu dGVyIFZhbiBkZSBWZWxkZSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+OyBQcmF2 ZWVuIE11bGV5IDxwcmF2ZWVuLm11bGV5QG5va2lhLmNvbT47IENvY2lnbGlvIE1hdXJvIDxt YXVyby5jb2NpZ2xpb0B0ZWxlY29taXRhbGlhLml0Pg0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrLTAx LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1maW9jY29sYS12Nm9wcy1p cHY2LWFsdC1tYXJrLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBHaXVzZXBwZSBGaW9jY29sYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrDQpSZXZpc2lv bjoJMDENClRpdGxlOgkJSVB2NiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCB3aXRoIEFsdGVy bmF0ZSBNYXJraW5nIE1ldGhvZA0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNi0wNQ0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW9jY29sYS12Nm9w cy1pcHY2LWFsdC1tYXJrLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpb2Njb2xhLXY2b3BzLWlwdjYtYWx0LW1hcmsv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZp b2Njb2xhLXY2b3BzLWlwdjYtYWx0LW1hcmstMDENCkh0bWxpemVkOiAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZpb2Njb2xhLXY2b3BzLWlw djYtYWx0LW1hcmsNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZmlvY2NvbGEtdjZvcHMtaXB2Ni1hbHQtbWFyay0wMQ0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgYWx0ZXJuYXRlIG1h cmtpbmcgbWV0aG9kIGluIFtSRkM4MzIxXQ0KICAgY2FuIGJlIHVzZWQgYXMgdGhlIHBhc3Np dmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgbWV0aG9kIGluIGFuIElQdjYNCiAgIGRvbWFp biwgYW5kIHdpbGwgZGlzY3VzcyB0aGUgc3RyZW5ndGhzIGFuZCB0aGUgd2Vha25lc3NlcyBv ZiB0aGUNCiAgIGltcGxlbWVudGF0aW9uIG9wdGlvbnMgYXZhaWxhYmxlIHRvIG5ldHdvcmsg b3BlcmF0aW9ucy4gIEl0IHByb3Bvc2VzDQogICBob3cgdG8gZXh0ZW5kIFtSRkM3ODM3XSB0 byBhcHBseSBhbHRlcm5hdGUgbWFya2luZyB0ZWNobmlxdWUuDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUg aSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2 dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJl Z2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRp IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFp biBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMp IG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnli b2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0K DQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9u IMOoIG5lY2Vzc2FyaW8uDQo= From nobody Tue Jun 5 08:57: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 C8244130FFF; Tue, 5 Jun 2018 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AquU5Jb6YXBq; Tue, 5 Jun 2018 06:11:55 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6784113104D; Tue, 5 Jun 2018 06:11:51 -0700 (PDT) X-AuditID: d9a97916-96bff700000010af-6c-5b168c159680 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id BD.F2.04271.51C861B5; Tue, 5 Jun 2018 15:11:49 +0200 (CEST) From: Fioccola Giuseppe To: "v6ops@ietf.org" , "6man (6man@ietf.org)" <6man@ietf.org>, "'ipv6@ietf.org'" CC: "Fred Baker (fredbaker.ietf@gmail.com)" , "Bob Hinden (bob.hinden@gmail.com)" , =?utf-8?B?T2xlIFRyw7hhbiAob3Ryb2FuQGVtcGxveWVlcy5vcmcp?= , "Roberta Maglione (robmgl) (robmgl@cisco.com)" , "draft-fioccola-v6ops-ipv6-alt-mark@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "v6ops-chairs@ietf.org" , "Suresh Krishnan (suresh@kaloom.com)" Thread-Topic: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-01.txt Thread-Index: AQHT/Mq4gvowBCH8aEGuHK9gYxuzyKRRnFew Date: Tue, 5 Jun 2018 13:11:48 +0000 Message-ID: References: <152820257094.18010.12115397077426983981.idtracker@ietfa.amsl.com> In-Reply-To: <152820257094.18010.12115397077426983981.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.249] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNKsWRmVeSWpSXmKPExsXCxfdHSle0RyzaoOECj8XuKdPYLFauuMtk sfX9PjaLY9MamS1uf21gtXh59j2TxeS2FWwWa3usLLZ1nWKxmPoYKHT62F5mB26PKb83snoc PPaR0WPnrLvsHkuW/GTyOH9lBnsAa1QDo01iXl5+SWJJqkJKanGyrZJLZnFyTmJmbmqRQkhq Tmpyfq6SQmaKrZKxkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3VfIM 9te1sDC11DVUsgssTS0uyVfITS0uTkxPz8xXSE1YL5gxcfsj1oIFUhUHlz9maWA8IdnFyMkh IWAi0bvwKXMXIxeHkMBUJol3HXsZQRJsAjYSB1+dYAOxRQSKJJ4cbWYDKWIWmMMiMePRVyaQ hLBAqMS2x5NZIIrCJLZtfMkMYRtJzF2zGCzOIqAiMWvPJFYQm1cgUGLL/MVgQ4UE/CQWTH7J DmJzCvhLrDvzGmwxo4CsxITdi8BsZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rBC2gcTWpftY IGxFid+df9ggbBmJhUcmA9VwAM3RlFi/Sx9ipKLElO6H7BDnCEqcnPmEZQKj2Cwk22YhdMxC 0jELSccCRpZVjKK5FQZGeiWQ6MssSczJTNTLLNnECExRN1dWiu1gbF3rfIhRgINRiYc3okEs Wog1say4MvcQowQHs5IIL487UIg3JbGyKrUoP76oNCe1+BCjDzC8JjJLiSbnA9NnXkm8oYmF paGxhYWRoYWZKQ5hJXHep6ZAswTSgekrOzW1ILUIZhwTB6dUA6PsmQdbrsll3pS9bPf4PuuD P8IHZf556wVaV2lZOG7YLPBy4oG1195lvYvX+BnXxrr46JLcct+LN55cj+o/m7sx6G4bj5ex ePi0P6azdxZUSPN1u65qmTz/rL+yjmxvpf1tFfeF820OT1mwn21ebnTc+gWHpad1B9lUrzko sqnLLKwiaKnpd00lluKMREMt5qLiRADaaul3fgMAAA== Archived-At: X-Mailman-Approved-At: Tue, 05 Jun 2018 08:57:28 -0700 Subject: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 13:12:01 -0000 SGkgQWxsLA0KWW91IG1heSByZWNhbGwgdGhlIHByZXNlbnRhdGlvbiBvZiBkcmFmdC1maW9j Y29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrIGluIGJvdGggNk1BTiBXRyBhbmQgVjZPUFMgV0cu DQpUaGlzIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgYWRkcmVzc2VzIHRoZSBjb21tZW50 cyByZWNlaXZlZCBkdXJpbmcgdGhlIExvbmRvbiBtZWV0aW5nIGFuZCB0aGUgZGlzY3Vzc2lv biB3ZSBoYWQgd2l0aCBGcmVkIEJha2VyLCBCb2IgSGluZGVuLCBPbGUgVHJvYW4gYW5kIFJv YmVydGEgTWFnbGlvbmUuIA0KVGhlIGNvbnNlbnN1cyB3YXMgdG8gY29uc2lkZXIgdGhlIENv bmV4IGV4dGVuc2lvbiBpbiBSRkM3ODM3IGFzIHRoZSBwcmVmZXJyZWQgb3B0aW9uIGFuZCB0 byBwcm9wb3NlIHRoZSB1c2Ugb2YgMiBiaXRzIGZyb20gdGhlIHJlc2VydmVkIGZpZWxkIGlu IHRoZSBSRkM3ODM3IENvbkV4IGV4dGVuc2lvbiB0byBlbmNvZGUgdGhlIG1hcmtpbmcgbWV0 aG9kLCBmdXJ0aGVybW9yZSBpdCB3aWxsIGJlIHVzZWQgYXMgSEJIIEhlYWRlci4NCg0KV291 bGQgYXBwcmVjaWF0ZSBhZGRpdGlvbmFsIGNvbW1lbnRzLg0KDQpCZXN0IFJlZ2FyZHMsDQoN CkdpdXNlcHBlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogbWFydGVkw6wgNSBnaXVnbm8gMjAxOCAxNDo0Mw0KVG86IEZpb2Njb2xhIEdpdXNl cHBlIDxnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0PjsgR3VudGVyIFZhbiBk ZSBWZWxkZSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+OyBQcmF2ZWVuIE11bGV5 IDxwcmF2ZWVuLm11bGV5QG5va2lhLmNvbT47IENvY2lnbGlvIE1hdXJvIDxtYXVyby5jb2Np Z2xpb0B0ZWxlY29taXRhbGlhLml0Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrLTAxLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1t YXJrLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBw ZSBGaW9jY29sYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 CQlkcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFsdC1tYXJrDQpSZXZpc2lvbjoJMDENClRp dGxlOgkJSVB2NiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCB3aXRoIEFsdGVybmF0ZSBNYXJr aW5nIE1ldGhvZA0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNi0wNQ0KR3JvdXA6CQlJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW9jY29sYS12Nm9wcy1pcHY2LWFs dC1tYXJrLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpb2Njb2xhLXY2b3BzLWlwdjYtYWx0LW1hcmsvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpb2Njb2xhLXY2 b3BzLWlwdjYtYWx0LW1hcmstMDENCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZpb2Njb2xhLXY2b3BzLWlwdjYtYWx0LW1h cmsNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtZmlvY2NvbGEtdjZvcHMtaXB2Ni1hbHQtbWFyay0wMQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgYWx0ZXJuYXRlIG1hcmtpbmcgbWV0 aG9kIGluIFtSRkM4MzIxXQ0KICAgY2FuIGJlIHVzZWQgYXMgdGhlIHBhc3NpdmUgcGVyZm9y bWFuY2UgbWVhc3VyZW1lbnQgbWV0aG9kIGluIGFuIElQdjYNCiAgIGRvbWFpbiwgYW5kIHdp bGwgZGlzY3VzcyB0aGUgc3RyZW5ndGhzIGFuZCB0aGUgd2Vha25lc3NlcyBvZiB0aGUNCiAg IGltcGxlbWVudGF0aW9uIG9wdGlvbnMgYXZhaWxhYmxlIHRvIG5ldHdvcmsgb3BlcmF0aW9u cy4gIEl0IHByb3Bvc2VzDQogICBob3cgdG8gZXh0ZW5kIFtSRkM3ODM3XSB0byBhcHBseSBh bHRlcm5hdGUgbWFya2luZyB0ZWNobmlxdWUuDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFs bGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUg ZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25v IHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBk YXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2Ug aXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBh ZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0 YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vz c2FyaW8uDQo= From nobody Tue Jun 5 13:03: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 791F7130DCF for ; Tue, 5 Jun 2018 13:02:57 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 VPSgnOik95xn for ; Tue, 5 Jun 2018 13:02:55 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5A6130DD0 for ; Tue, 5 Jun 2018 13:02:54 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76-v6so5071822itx.4 for ; Tue, 05 Jun 2018 13:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Va0crwRxt9JaNdPMUxPMePHsxxrTGnZa5uX00Zgenn0=; b=gFLYTBHZkz7Y0DyIxEdC+v/pKjIwYQFtjv+4cO6iFFDW5TwarO+AGfwONAQ5Az1CvH K8i2tULIA5gmYjzeXhPwmsq/Rc39TXAm3angK0MBidxa5w89A/bcPj/igY5o2NafYS2t yrP7g5uRXN2eI+2FrZTS6abvyF4BS/gRwo591uagZe8mDOLxkonLXl88EqqasN0IDsSi YAw3WkA8U9lIRF+S3MDXn7xna8JyM3tFP2xxzfl7sJZmU5idgvhUTv51pxXPkP8QfkvZ LFGQZ5N4JB71KEVrdmE3w1G8lDonsQZr30FUCM50WGn09R5rYEOhxCl7OZB8DLiMYM7p dFkQ== 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=Va0crwRxt9JaNdPMUxPMePHsxxrTGnZa5uX00Zgenn0=; b=Y+gxsXxexaMKAfeU28oDjwrVY7zciBlC+X+q72hUNXLf29R+Hui5r4n5h+8v4DoSzZ O2rHM1pqBp4R0UeU+A2pC6KtfJm7dxrd+uuISReHKxEiBeYuxZYFPZ+nT+uzMv1HJQtt /1rqllA6Lm9lpjFSqz1DxTupH7EbyX2Ve3Vb1HZ7pfE3XGZVRTv3dpTA0P7WmAYWVdz3 dAjPnO4aj/wEHiJlVRhUBighIppMxVcInstJdiWkBPyP+h+WEZSUuEJuNrmU0CafRZip mpoj4FsDQi50ce7Eja8Rav7EHU5mSf0Mbl8ke1n8wOQmwSUsGTvzBPldPjRGxMhTdgA/ eXUg== X-Gm-Message-State: APt69E0W4kWupaJiavWum1ZRX90IvVM2Y7Bdoc5JUgtWzaDJYIG/wPEc EU6uPYLgTqW1jZ9klzc0OwAuwoYD X-Google-Smtp-Source: ADUXVKJnapn4jrLYBgA0wXOCdglIWryVevY3oV0WHfVzZc+RqQ8hR51kG+sd7bKwD/bPocxZk2Y0Gw== X-Received: by 2002:a24:8681:: with SMTP id u123-v6mr722508itd.2.1528228973802; Tue, 05 Jun 2018 13:02:53 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id z70-v6sm1087602itb.14.2018.06.05.13.02.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 13:02:52 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id u4-v6so4882166iof.2; Tue, 05 Jun 2018 13:02:52 -0700 (PDT) X-Received: by 2002:a6b:1884:: with SMTP id 126-v6mr44464ioy.183.1528228972373; Tue, 05 Jun 2018 13:02:52 -0700 (PDT) MIME-Version: 1.0 From: Richard Patterson Date: Tue, 5 Jun 2018 21:02:40 +0100 X-Gmail-Original-Message-ID: Message-ID: To: int-area@ietf.org, "v6ops@ietf.org list" , dhcwg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 20:02:58 -0000 Hi All, The above new draft has been posted to address an operational problem that exists with current IPoE (non-PPPoE) fixed line broadband services. It can be found here: https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ Hopefully the draft covers the problem statement sufficiently, but in summary, PPPoE makes use of LCP echo/replies to detect WAN failures, DHCPv4/6 currently has no such mechanism. After backhaul migrations or BNG maintenance/failure, an IPoE client can be left with a stale DHCP lease for up to the Valid Lifetime. This draft proposes the use of regular ARP and ND for link monitoring, to proactively expire DHCP leases early, and to trigger renewals or getting a new lease from scratch. The intarea WG was chosen as it doesn't neatly fit within the charters of either v6ops or dhc, and because it proposes new DHCPv4 and DHCPv6 Options. Although we expect discussions in both of these WGs as well. Thanks for comments already received from Ian, and Bernie, that helped shape this -00. -Richard From nobody Wed Jun 6 05:25: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 AC171130EF3 for ; Wed, 6 Jun 2018 05:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 bdYkt06nMv6k for ; Wed, 6 Jun 2018 05:25:16 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD46130E60 for ; Wed, 6 Jun 2018 05:25:13 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id g22-v6so7359089iob.7 for ; Wed, 06 Jun 2018 05:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=E83pr3zxuC5JNLDKcbxP5hsHjkNmdsa6U133wx1d9CQ=; b=lXF5TQqj7EbSzSF4kURxyOaPai/cNswncSb+5CTURWHPw48Z61jp63t0Qmd9X/bim7 iYgoG7PuD9YsvzbnaPNIEEX14hydb4/6LiWK5F+2ggliyjqwJdgptjGIKNJzwtsW6SHz KYmO4tpxgeD+RHeByrzJRCVzSaimUU1IKGdNevnNHHo9VgbhqP9V8V4A9KME1Hqm8Ofj vTRawV5wxmsueMctGrCJiAVCtyomX+oxBuD51B+6VNBnwWG1/PxdZHPtgSmujKM4aQ1I LEaVk+TiBHz0KWcvw3EThYUZSFdTIdeLCJz4xcJKl4KdqqOgcmlsYtCRQWydBaSHLoH9 WzMA== 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:content-transfer-encoding; bh=E83pr3zxuC5JNLDKcbxP5hsHjkNmdsa6U133wx1d9CQ=; b=NH/hR5AVt/cjIYEbj+hPs649K3Igi7BBB68DvCkQozgiCIxF+0ILcwRFvu1dGBa/hU NCcFdARseOloWZla9+uhaBBttbg/8nxBgkKF9WJsRJE+tKi4u1tcy4A3oY/6XiJt0cDr F4x3torE645duTwAhi8AL+uo38KLAhKHPbttcDd0s8Yf+YjE7Rn52Ftr5Tq/FwNhttyd wMCk5JkbRlu8DdxEYwQkJ7WMdo2e5jO+aRHvRsC5d+eW7JF71/QorVXAI+aflR/UKKjI 5Ty/zYZCKFFWdMUe4OYYrOgn7/LN7VZVfHU33d78HZHCdgIp/adHLotLdQw/q0DpU0+8 GxbA== X-Gm-Message-State: APt69E3kR3HzQXDrStoZmMbbU842jHTWPsFzX0WzwyPZP7knHiietjAk xvEAHLlW7ZtWOtdOEU5LPqgeW4Rq X-Google-Smtp-Source: ADUXVKLAGejFWe/sWo63xDTpFMLjTZCqTAZMPJ6V+0ATP/oruJJHHDMVhpIqAXFOE6TFMH+3rTT0tw== X-Received: by 2002:a6b:c80f:: with SMTP id y15-v6mr2692566iof.187.1528287912518; Wed, 06 Jun 2018 05:25:12 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id s9-v6sm4315174ioa.66.2018.06.06.05.25.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 05:25:11 -0700 (PDT) Received: by mail-io0-f175.google.com with SMTP id f1-v6so7355104ioh.6 for ; Wed, 06 Jun 2018 05:25:11 -0700 (PDT) X-Received: by 2002:a6b:204a:: with SMTP id g71-v6mr2563866iog.172.1528287911532; Wed, 06 Jun 2018 05:25:11 -0700 (PDT) MIME-Version: 1.0 References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> In-Reply-To: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> From: Richard Patterson Date: Wed, 6 Jun 2018 13:25:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , jordi.palet=40consulintel.es@dmarc.ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:25:23 -0000 Hi Jordi, I'm not sure that I agree with requirement TRANS-2: "The IPv6 Transition CE Router MUST verify if the WAN link supports native IPv4. In that case, transition mechanisms SHOULD NOT be automatically enabled for that interface." In fact I'd suggest the exact opposite, if a CE Router receives valid S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations until the WAN link status changes. This could be expanded to include a validation of a working IPv4aaS, but unsure how that should look. For example, a brownfield IPv4aaS deployment is likely to still be running dual stack in parallel whilst it migrates its clients to IPv4aaS, the current wording would hinder this migration, by preferring to stay on native (or NAT444) IPv4. The "suspend" could also be debated, that it could be sufficient to rely on the DHCPv4 back off mechanisms, but on a large network that could still put a lot of extra load on the DHCPv4 server/relay and RADIUS. My vote is to suspend temporarily until reboot/WAN change. And anecdotally, the current behaviour of OpenWRT is to prefer the S46 IPv4aaS mechanism, even when presented a valid DHCPv4 lease. -Richard On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ wrote: > > Hi Barbara, > > Sorry the late answer, last few weeks had been a non-stop traveling in 3 = continents and too much work ... > > I see what you mean and we have discussed about this among the coauthors = and amended the document, including some other comments received in the lis= t. > > The new version has been published a few minutes ago: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inc= lude_text=3D1 > > Basically, we are keeping a MUST for retail product versions, but not for= specific ISP versions. I hope you agree with this, as we believe it makes = sense. > > We don't update anymore the RFC7084, and we just use the same style to ad= d the requirements for an IPv6 Transition CE Router (and we use this termin= ology across all the document). > > The main changes are summarized in the Annex C: > 1. ID-Nits: IANA section. > 2. ID-Nits: RFC7084 reference removed from Abstract. > 3. This document no longer updates RFC7084. > 4. UPnP section reworded. > 5. "CE Router" changed to "IPv6 Transition CE Router". > 6. Reduced text in Annex A. > > Hopefully everybody agrees now with this version, and in any case, will b= e very helpful if we can get any inputs. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de "STARK, BARBARA H" > Fecha: lunes, 30 de abril de 2018, 19:20 > Para: V6 Ops List > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.tx= t > > Hi Jordi, > I was having a hard time understanding where you were headed with pro= posed changes, by following the email thread. So I was waiting for this upd= ate. My company's email server also refuses to deliver to me some emails se= nt to this list without telling me. That probably adds to my difficulty. > > My suggestion related to making requirements "MUST" were tied to also= *not* making this an update to RFC 7084. > > Here is the problem: > If this is an update to RFC 7084, then I cannot support any "MUST" st= atements. > My employer makes use of RFC 7084. As is. Updating RFC 7084 with addi= tional "MUST" statements impacts my employer's ability to use and reference= RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST" st= atements (that are not needed by many current deployments) would be harmful= to the existing IPv6 ecosystem. > > For a device profile to be usable by the vendor and ISP community, it= must contain "MUST" statements for all items that need to be required to a= chieve the profile's goal. Trying to get vendors to implement lots of "SHOU= LD" statements is futile. As an individual contributor, I do not support IE= TF publishing a futile device profile document with many "SHOULD" statement= s. > > The solution I have proposed is to create a brand new device profile.= A device profile for something called an "IPv6 Transition CE Router". This= device profile is not an update to RFC 7084. It is its own thing. It is fr= ee to make use of RFC 7084 any way it wants -- not at all, in whole, or by = referencing sections it does or doesn't want to require as part of the "IPv= 6 Transition CE Router" device profile. > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jun 6 05:33: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 5DCA0130EF7 for ; Wed, 6 Jun 2018 05:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm0P_9ZkVfvI for ; Wed, 6 Jun 2018 05:33:20 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12617130EED for ; Wed, 6 Jun 2018 05:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528288398; x=1528893198; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=ivdF1FG8 Ihv7fcMFZjijjJu5Lmol02N7RqdgbC6gSz8=; b=wHAccnpxP8YKO5EsZFD7C0+s bbUrFSbja4fnDfBTqfFodpnsRPai4SndFt0BlPsC1lp6TEuUwQuebc9DPmY0XyIf XJtpFhM7mBsfoO0QzDxUNk2vTZ1Ur7bLWIcmowN6RBztQaieEyJR21UHaQrlevxs pnl/aFa33LqZ0n9wAaM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 14:33:18 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 14:33:17 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783191.msg for ; Wed, 06 Jun 2018 14:33:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 14:33:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 14:33:14 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:33:28 -0000 Hi Richard, This is an interesting perspective ... What we prefer "the best quality" that dual-stack can offer, or even if you= have lower quality, "push for IPv6" ? Would not be better that if your network is offering already IPv4-as-a-serv= ice, you stop DHCPv4/PPP ? I think that way, you, the ISP, have a better control for those customers t= hat you want to provide "native-IPv4" vs transition. I will like to heard what other people believes about this. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Richard Patterson Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:26 Para: "v6ops@ietf.org list" , Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Hi Jordi, =20 I'm not sure that I agree with requirement TRANS-2: "The IPv6 Transition CE Router MUST verify if the WAN link supports native IPv4. In that case, transition mechanisms SHOULD NOT be automatically enabled for that interface." =20 In fact I'd suggest the exact opposite, if a CE Router receives valid S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations until the WAN link status changes. This could be expanded to include a validation of a working IPv4aaS, but unsure how that should look. For example, a brownfield IPv4aaS deployment is likely to still be running dual stack in parallel whilst it migrates its clients to IPv4aaS, the current wording would hinder this migration, by preferring to stay on native (or NAT444) IPv4. =20 The "suspend" could also be debated, that it could be sufficient to rely on the DHCPv4 back off mechanisms, but on a large network that could still put a lot of extra load on the DHCPv4 server/relay and RADIUS. My vote is to suspend temporarily until reboot/WAN change. =20 And anecdotally, the current behaviour of OpenWRT is to prefer the S46 IPv4aaS mechanism, even when presented a valid DHCPv4 lease. =20 -Richard On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ wrote: > > Hi Barbara, > > Sorry the late answer, last few weeks had been a non-stop traveling i= n 3 continents and too much work ... > > I see what you mean and we have discussed about this among the coauth= ors and amended the document, including some other comments received in the= list. > > The new version has been published a few minutes ago: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/= ?include_text=3D1 > > Basically, we are keeping a MUST for retail product versions, but not= for specific ISP versions. I hope you agree with this, as we believe it ma= kes sense. > > We don't update anymore the RFC7084, and we just use the same style t= o add the requirements for an IPv6 Transition CE Router (and we use this te= rminology across all the document). > > The main changes are summarized in the Annex C: > 1. ID-Nits: IANA section. > 2. ID-Nits: RFC7084 reference removed from Abstract. > 3. This document no longer updates RFC7084. > 4. UPnP section reworded. > 5. "CE Router" changed to "IPv6 Transition CE Router". > 6. Reduced text in Annex A. > > Hopefully everybody agrees now with this version, and in any case, wi= ll be very helpful if we can get any inputs. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de "STARK, BARBARA H" > Fecha: lunes, 30 de abril de 2018, 19:20 > Para: V6 Ops List > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 0.txt > > Hi Jordi, > I was having a hard time understanding where you were headed with= proposed changes, by following the email thread. So I was waiting for this= update. My company's email server also refuses to deliver to me some email= s sent to this list without telling me. That probably adds to my difficulty= . > > My suggestion related to making requirements "MUST" were tied to = also *not* making this an update to RFC 7084. > > Here is the problem: > If this is an update to RFC 7084, then I cannot support any "MUST= " statements. > My employer makes use of RFC 7084. As is. Updating RFC 7084 with = additional "MUST" statements impacts my employer's ability to use and refer= ence RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST= " statements (that are not needed by many current deployments) would be har= mful to the existing IPv6 ecosystem. > > For a device profile to be usable by the vendor and ISP community= , it must contain "MUST" statements for all items that need to be required = to achieve the profile's goal. Trying to get vendors to implement lots of "= SHOULD" statements is futile. As an individual contributor, I do not suppor= t IETF publishing a futile device profile document with many "SHOULD" state= ments. > > The solution I have proposed is to create a brand new device prof= ile. A device profile for something called an "IPv6 Transition CE Router". = This device profile is not an update to RFC 7084. It is its own thing. It i= s free to make use of RFC 7084 any way it wants -- not at all, in whole, or= by referencing sections it does or doesn't want to require as part of the = "IPv6 Transition CE Router" device profile. > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > 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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 05: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 E0E71130F24 for ; Wed, 6 Jun 2018 05:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 pboQMtSxbXWJ for ; Wed, 6 Jun 2018 05:54:21 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B318130F03 for ; Wed, 6 Jun 2018 05:54:17 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y127-v6so16157258itd.1 for ; Wed, 06 Jun 2018 05:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=c9NP3MfYPTUM53sqqQ+Xfsw8KjRQS/opUqEnfvHpNvI=; b=e5TxPcCDelJGNPDwoqC5lA76Y8g5I3P9RSgEbj/CLe8HNKmNCcUJ1xaNwHaoksUoun m7fC9rqmdj404q9K2PDC92VqF+qxTcxSHHgh2TfTh31CDQDET8Jt9LrBwK6iXCv3GDF9 dOFn7YXMxCHqcEiNN+lYgG6ytnKyxStKmdJPChbi4q2MByTVDo20doQ3WhokuS6WIG/S qtJfVYlR/cumAtBI0U7dwjPROEwQmmVKQey65FZxkovYyYm9S7oCvh4SHgtj95cxg3xb Zw0zOpcrM5nGxuM3T1o9y7SD9KZQ1IdA/gPQFYtMIx9GIFrrL/CIv6d5fCIVAqHEcy27 Oujw== 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:content-transfer-encoding; bh=c9NP3MfYPTUM53sqqQ+Xfsw8KjRQS/opUqEnfvHpNvI=; b=ojV+Iob9Ze0Kq/D+iFzRe2LP/4UvGBDU4FrJrUrwV2hz3J4mlaxMXsi5plBxNHM/Pp tzbD+4/Fz1W9cgyg9+bDgtJhxFEfCdWHWoX0MpNXu2f0v2CRyv2/M6XiyrS8BXjpkKfD /jRBOy0KNcV5iS/fzvN1qFfTiPTksRI7uoWzWV05g3lmYK1dqGBOchkfKbLjrv3ewC6E HtzwLZ7uerWu/nj0j0YV60Uapok2zusjSdbUjD7frc0klp2t/b2uZGM010mISLtOsQnJ W2gpLiWH25fAKMxuDJOPQjqJP4f5GL6noxyS/ixiuCdsYxm0B1++M34b1DE7bA4S78+O UWlg== X-Gm-Message-State: APt69E2OpTXahq/61H/DR77rLJ3VCLPE/+lf5aZixjGMHw9L6WCWu+GX awxuPizkdkr5lBrCdnQva9nD8M5w X-Google-Smtp-Source: ADUXVKL93C5/s2GHKt6k91LAnqbfQ1GKrOnbEcPHVixul5vmLn7g6RwR69IMCGb9BQ8LGLcx9P9ODw== X-Received: by 2002:a24:af04:: with SMTP id t4-v6mr2333859ite.11.1528289656284; Wed, 06 Jun 2018 05:54:16 -0700 (PDT) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id w73-v6sm1750792ita.39.2018.06.06.05.54.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 05:54:15 -0700 (PDT) Received: by mail-it0-f53.google.com with SMTP id a195-v6so7901192itd.3 for ; Wed, 06 Jun 2018 05:54:15 -0700 (PDT) X-Received: by 2002:a24:e3ca:: with SMTP id d193-v6mr2282528ith.130.1528289655159; Wed, 06 Jun 2018 05:54:15 -0700 (PDT) MIME-Version: 1.0 References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> In-Reply-To: <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> From: Richard Patterson Date: Wed, 6 Jun 2018 13:54:03 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , jordi.palet=40consulintel.es@dmarc.ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:54:35 -0000 At the moment the current wording overrides the presence of DHCPv6 S46 Options, this prevents the ISP from doing a per-subscriber granular migration. eg. by including it within a RADIUS Access-Accept Attribute or not. Disabling of the DHCPv4 server forces a big bang migration strategy; The ISP may not have the luxury to upgrade all the CPE types on the network to ones that support IPv4aaS method, so a big bang migration wouldn't be feasible. Regarding the quality argument, this makes the assumption that all IPv4aaS methods mentioned are worse than native IPv4. There's no qualification on if that native IPv4 is actually behind NAT444 or not. I'd say that if the ISP is returning valid S46 Options, then they want or even expect the client to make use of them, not ignore them. -Richard On Wed, 6 Jun 2018 at 13:34, JORDI PALET MARTINEZ wrote: > > Hi Richard, > > This is an interesting perspective ... > > What we prefer "the best quality" that dual-stack can offer, or even if y= ou have lower quality, "push for IPv6" ? > > Would not be better that if your network is offering already IPv4-as-a-se= rvice, you stop DHCPv4/PPP ? > > I think that way, you, the ISP, have a better control for those customers= that you want to provide "native-IPv4" vs transition. > > I will like to heard what other people believes about this. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Richard Patterson > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:26 > Para: "v6ops@ietf.org list" , > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.tx= t > > Hi Jordi, > > I'm not sure that I agree with requirement TRANS-2: > "The IPv6 Transition CE Router MUST verify if the WAN link supports > native IPv4. In that case, transition mechanisms SHOULD NOT be > automatically enabled for that interface." > > In fact I'd suggest the exact opposite, if a CE Router receives valid > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations > until the WAN link status changes. This could be expanded to include > a validation of a working IPv4aaS, but unsure how that should look. > For example, a brownfield IPv4aaS deployment is likely to still be > running dual stack in parallel whilst it migrates its clients to > IPv4aaS, the current wording would hinder this migration, by > preferring to stay on native (or NAT444) IPv4. > > The "suspend" could also be debated, that it could be sufficient to > rely on the DHCPv4 back off mechanisms, but on a large network that > could still put a lot of extra load on the DHCPv4 server/relay and > RADIUS. My vote is to suspend temporarily until reboot/WAN change. > > And anecdotally, the current behaviour of OpenWRT is to prefer the S4= 6 > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. > > -Richard > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > wrote: > > > > Hi Barbara, > > > > Sorry the late answer, last few weeks had been a non-stop traveling= in 3 continents and too much work ... > > > > I see what you mean and we have discussed about this among the coau= thors and amended the document, including some other comments received in t= he list. > > > > The new version has been published a few minutes ago: > > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aa= s/?include_text=3D1 > > > > Basically, we are keeping a MUST for retail product versions, but n= ot for specific ISP versions. I hope you agree with this, as we believe it = makes sense. > > > > We don't update anymore the RFC7084, and we just use the same style= to add the requirements for an IPv6 Transition CE Router (and we use this = terminology across all the document). > > > > The main changes are summarized in the Annex C: > > 1. ID-Nits: IANA section. > > 2. ID-Nits: RFC7084 reference removed from Abstract. > > 3. This document no longer updates RFC7084. > > 4. UPnP section reworded. > > 5. "CE Router" changed to "IPv6 Transition CE Router". > > 6. Reduced text in Annex A. > > > > Hopefully everybody agrees now with this version, and in any case, = will be very helpful if we can get any inputs. > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: v6ops en nombre de "STARK, BARBARA H" = > > Fecha: lunes, 30 de abril de 2018, 19:20 > > Para: V6 Ops List > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas= -00.txt > > > > Hi Jordi, > > I was having a hard time understanding where you were headed wi= th proposed changes, by following the email thread. So I was waiting for th= is update. My company's email server also refuses to deliver to me some ema= ils sent to this list without telling me. That probably adds to my difficul= ty. > > > > My suggestion related to making requirements "MUST" were tied t= o also *not* making this an update to RFC 7084. > > > > Here is the problem: > > If this is an update to RFC 7084, then I cannot support any "MU= ST" statements. > > My employer makes use of RFC 7084. As is. Updating RFC 7084 wit= h additional "MUST" statements impacts my employer's ability to use and ref= erence RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MU= ST" statements (that are not needed by many current deployments) would be h= armful to the existing IPv6 ecosystem. > > > > For a device profile to be usable by the vendor and ISP communi= ty, it must contain "MUST" statements for all items that need to be require= d to achieve the profile's goal. Trying to get vendors to implement lots of= "SHOULD" statements is futile. As an individual contributor, I do not supp= ort IETF publishing a futile device profile document with many "SHOULD" sta= tements. > > > > The solution I have proposed is to create a brand new device pr= ofile. A device profile for something called an "IPv6 Transition CE Router"= . This device profile is not an update to RFC 7084. It is its own thing. It= is free to make use of RFC 7084 any way it wants -- not at all, in whole, = or by referencing sections it does or doesn't want to require as part of th= e "IPv6 Transition CE Router" device profile. > > Barbara > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jun 6 06:41: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 1B9D1130F1E for ; Wed, 6 Jun 2018 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njKdiLmS-DDA for ; Wed, 6 Jun 2018 06:40:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF357130F21 for ; Wed, 6 Jun 2018 06:40:53 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w56DYa6Y043029; Wed, 6 Jun 2018 09:40:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2jefyfjdc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 09:40:49 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56DemDg025688; Wed, 6 Jun 2018 09:40:49 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56Dehcn025581; Wed, 6 Jun 2018 09:40:43 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 75EFC40002BD; Wed, 6 Jun 2018 13:40:43 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30483.vci.att.com (Service) with ESMTPS id 5746840002A7; Wed, 6 Jun 2018 13:40:43 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0399.000; Wed, 6 Jun 2018 09:40:42 -0400 From: "STARK, BARBARA H" To: "'Richard Patterson'" , "v6ops@ietf.org list" , "jordi.palet=40consulintel.es@dmarc.ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Thread-Index: AQHT9mNCLmiS3PpdIUysWpj3Js08m6RTeQ0AgAACTQCAAAXRgP//xwWA Date: Wed, 6 Jun 2018 13:40:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060158 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 13:40:59 -0000 PiBBdCB0aGUgbW9tZW50IHRoZSBjdXJyZW50IHdvcmRpbmcgb3ZlcnJpZGVzIHRoZSBwcmVzZW5j ZSBvZiBESENQdjYgUzQ2DQo+IE9wdGlvbnMsIHRoaXMgcHJldmVudHMgdGhlIElTUCBmcm9tIGRv aW5nIGEgcGVyLXN1YnNjcmliZXIgZ3JhbnVsYXINCj4gbWlncmF0aW9uLiBlZy4gYnkgaW5jbHVk aW5nIGl0IHdpdGhpbiBhIFJBRElVUyBBY2Nlc3MtQWNjZXB0IEF0dHJpYnV0ZSBvciBub3QuDQo+ IA0KPiBEaXNhYmxpbmcgb2YgdGhlIERIQ1B2NCBzZXJ2ZXIgZm9yY2VzIGEgYmlnIGJhbmcgbWln cmF0aW9uIHN0cmF0ZWd5OyBUaGUgSVNQDQo+IG1heSBub3QgaGF2ZSB0aGUgbHV4dXJ5IHRvIHVw Z3JhZGUgYWxsIHRoZSBDUEUgdHlwZXMgb24gdGhlIG5ldHdvcmsgdG8gb25lcw0KPiB0aGF0IHN1 cHBvcnQgSVB2NGFhUyBtZXRob2QsIHNvIGEgYmlnIGJhbmcgbWlncmF0aW9uIHdvdWxkbid0IGJl IGZlYXNpYmxlLg0KPiANCj4gUmVnYXJkaW5nIHRoZSBxdWFsaXR5IGFyZ3VtZW50LCB0aGlzIG1h a2VzIHRoZSBhc3N1bXB0aW9uIHRoYXQgYWxsIElQdjRhYVMNCj4gbWV0aG9kcyBtZW50aW9uZWQg YXJlIHdvcnNlIHRoYW4gbmF0aXZlIElQdjQuICBUaGVyZSdzIG5vIHF1YWxpZmljYXRpb24gb24N Cj4gaWYgdGhhdCBuYXRpdmUgSVB2NCBpcyBhY3R1YWxseSBiZWhpbmQgTkFUNDQ0IG9yIG5vdC4N Cj4gSSdkIHNheSB0aGF0IGlmIHRoZSBJU1AgaXMgcmV0dXJuaW5nIHZhbGlkIFM0NiBPcHRpb25z LCB0aGVuIHRoZXkgd2FudCBvciBldmVuDQo+IGV4cGVjdCB0aGUgY2xpZW50IHRvIG1ha2UgdXNl IG9mIHRoZW0sIG5vdCBpZ25vcmUgdGhlbS4NCj4gDQo+IC1SaWNoYXJkDQoNCkkgdGhpbmsgSSBh Z3JlZSB3aXRoIFJpY2hhcmQgb24gdGhpcy4gSWYgYW4gSVNQIGFscmVhZHkgaGFzIGR1YWwgc3Rh Y2sgZGVwbG95ZWQgYW5kIGlzIHN0YXJ0aW5nIGRlcGxveW1lbnQgb2YgYW4gSVB2NGFhUyB0ZWNo bm9sb2d5LCBvciBoYXMgc2ltdWx0YW5lb3VzbHkgZGVwbG95ZWQgZHVhbCBzdGFjayB3aXRoIElQ djRhYVMsIHRoZW4gdGhlIGdvYWwgbXVzdCBjbGVhcmx5IGJlIHRvIG1vdmUgcGVvcGxlIHRvIHRo ZSBJUHY0YWFTIHRlY2hub2xvZ3kuIElmIGFuIElTUCBoYXMgSVB2NGFhUyBkZXBsb3llZCwgaXQg aXMgaGlnaGx5IHVubGlrZWx5IHRoZXkgd2lsbCB0aGVuIGRlcGxveSBkdWFsIHN0YWNrLiBTbyB0 aGUgcHJlc2VuY2Ugb2YgYm90aCBkdWFsIHN0YWNrIGFuZCBJUHY0YWFTIG11c3QgYmUgYW4gaW5k aWNhdGlvbiB0aGUgSVNQIHdhbnRzIHRvIG1vdmUgcGVvcGxlIG9mZiBkdWFsIHN0YWNrIGFuZCBv bnRvIElQdjRhYVMuDQoNCklQdjRhYVMgc2hvdWxkIGJlIHRoZSBwcmVmZXJyZWQgY29ubmVjdGlv biBpbiB0aGlzIGNhc2UsIGluIG9yZGVyIHRvIGFjaGlldmUgYSBzbW9vdGhlciB0cmFuc2l0aW9u LiBOb3RlIHRoYXQgSVB2NiB3YXNuJ3QgYWx3YXlzICJiZXR0ZXIiIHRoYW4gSVB2NCAoaXQgb2Z0 ZW4gaGFkIGhpZ2hlciBsYXRlbmN5KSwgYnV0IHdlIHN0aWxsIGFsbCBhZ3JlZWQgaXQgc2hvdWxk IGJlICJwcmVmZXJyZWQiLiBJIHRoaW5rIHRoaXMgaXMgdGhlIHNhbWUuDQpCYXJiYXJhDQoNCg0K PiBPbiBXZWQsIDYgSnVuIDIwMTggYXQgMTM6MzQsIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQo+IDxq b3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPg0K PiA+IEhpIFJpY2hhcmQsDQo+ID4NCj4gPiBUaGlzIGlzIGFuIGludGVyZXN0aW5nIHBlcnNwZWN0 aXZlIC4uLg0KPiA+DQo+ID4gV2hhdCB3ZSBwcmVmZXIgInRoZSBiZXN0IHF1YWxpdHkiIHRoYXQg ZHVhbC1zdGFjayBjYW4gb2ZmZXIsIG9yIGV2ZW4gaWYgeW91DQo+IGhhdmUgbG93ZXIgcXVhbGl0 eSwgInB1c2ggZm9yIElQdjYiID8NCj4gPg0KPiA+IFdvdWxkIG5vdCBiZSBiZXR0ZXIgdGhhdCBp ZiB5b3VyIG5ldHdvcmsgaXMgb2ZmZXJpbmcgYWxyZWFkeSBJUHY0LWFzLWEtDQo+IHNlcnZpY2Us IHlvdSBzdG9wIERIQ1B2NC9QUFAgPw0KPiA+DQo+ID4gSSB0aGluayB0aGF0IHdheSwgeW91LCB0 aGUgSVNQLCBoYXZlIGEgYmV0dGVyIGNvbnRyb2wgZm9yIHRob3NlIGN1c3RvbWVycw0KPiB0aGF0 IHlvdSB3YW50IHRvIHByb3ZpZGUgIm5hdGl2ZS1JUHY0IiB2cyB0cmFuc2l0aW9uLg0KPiA+DQo+ ID4gSSB3aWxsIGxpa2UgdG8gaGVhcmQgd2hhdCBvdGhlciBwZW9wbGUgYmVsaWV2ZXMgYWJvdXQg dGhpcy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gSm9yZGkNCj4gPg0KPiA+DQo+ID4NCj4gPiDv u78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNl c0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIFJpY2hhcmQgUGF0dGVyc29uDQo+ID4gPHJpY2hhcmRA aGVsaXgubmV0Lm56Pg0KPiA+IEZlY2hhOiBtacOpcmNvbGVzLCA2IGRlIGp1bmlvIGRlIDIwMTgs IDE0OjI2DQo+ID4gUGFyYTogInY2b3BzQGlldGYub3JnIGxpc3QiIDx2Nm9wc0BpZXRmLm9yZz4s DQo+ID4gPGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+DQo+ID4g QXN1bnRvOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOg0KPiA+IGRyYWZ0LWlldGYtdjZvcHMtdHJh bnNpdGlvbi1pcHY0YWFzLTAwLnR4dA0KPiA+DQo+ID4gICAgIEhpIEpvcmRpLA0KPiA+DQo+ID4g ICAgIEknbSBub3Qgc3VyZSB0aGF0IEkgYWdyZWUgd2l0aCByZXF1aXJlbWVudCBUUkFOUy0yOg0K PiA+ICAgICAiVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVTVCB2ZXJpZnkgaWYgdGhl IFdBTiBsaW5rIHN1cHBvcnRzDQo+ID4gICAgIG5hdGl2ZSBJUHY0LiAgSW4gdGhhdCBjYXNlLCB0 cmFuc2l0aW9uIG1lY2hhbmlzbXMgU0hPVUxEIE5PVCBiZQ0KPiA+ICAgICBhdXRvbWF0aWNhbGx5 IGVuYWJsZWQgZm9yIHRoYXQgaW50ZXJmYWNlLiINCj4gPg0KPiA+ICAgICBJbiBmYWN0IEknZCBz dWdnZXN0IHRoZSBleGFjdCBvcHBvc2l0ZSwgaWYgYSBDRSBSb3V0ZXIgcmVjZWl2ZXMgdmFsaWQN Cj4gPiAgICAgUzQ2IERIQ1AgT3B0aW9ucywgaXQgU0hPVUxEIHN1c3BlbmQgaXRzIERIQ1B2NC9Q UFAgSVBDUCBvcGVyYXRpb25zDQo+ID4gICAgIHVudGlsIHRoZSBXQU4gbGluayBzdGF0dXMgY2hh bmdlcy4gIFRoaXMgY291bGQgYmUgZXhwYW5kZWQgdG8gaW5jbHVkZQ0KPiA+ICAgICBhIHZhbGlk YXRpb24gb2YgYSB3b3JraW5nIElQdjRhYVMsIGJ1dCB1bnN1cmUgaG93IHRoYXQgc2hvdWxkIGxv b2suDQo+ID4gICAgIEZvciBleGFtcGxlLCBhIGJyb3duZmllbGQgSVB2NGFhUyBkZXBsb3ltZW50 IGlzIGxpa2VseSB0byBzdGlsbCBiZQ0KPiA+ICAgICBydW5uaW5nIGR1YWwgc3RhY2sgaW4gcGFy YWxsZWwgd2hpbHN0IGl0IG1pZ3JhdGVzIGl0cyBjbGllbnRzIHRvDQo+ID4gICAgIElQdjRhYVMs IHRoZSBjdXJyZW50IHdvcmRpbmcgd291bGQgaGluZGVyIHRoaXMgbWlncmF0aW9uLCBieQ0KPiA+ ICAgICBwcmVmZXJyaW5nIHRvIHN0YXkgb24gbmF0aXZlIChvciBOQVQ0NDQpIElQdjQuDQo+ID4N Cj4gPiAgICAgVGhlICJzdXNwZW5kIiBjb3VsZCBhbHNvIGJlIGRlYmF0ZWQsIHRoYXQgaXQgY291 bGQgYmUgc3VmZmljaWVudCB0bw0KPiA+ICAgICByZWx5IG9uIHRoZSBESENQdjQgYmFjayBvZmYg bWVjaGFuaXNtcywgYnV0IG9uIGEgbGFyZ2UgbmV0d29yayB0aGF0DQo+ID4gICAgIGNvdWxkIHN0 aWxsIHB1dCBhIGxvdCBvZiBleHRyYSBsb2FkIG9uIHRoZSBESENQdjQgc2VydmVyL3JlbGF5IGFu ZA0KPiA+ICAgICBSQURJVVMuICAgTXkgdm90ZSBpcyB0byBzdXNwZW5kIHRlbXBvcmFyaWx5IHVu dGlsIHJlYm9vdC9XQU4gY2hhbmdlLg0KPiA+DQo+ID4gICAgIEFuZCBhbmVjZG90YWxseSwgdGhl IGN1cnJlbnQgYmVoYXZpb3VyIG9mIE9wZW5XUlQgaXMgdG8gcHJlZmVyIHRoZSBTNDYNCj4gPiAg ICAgSVB2NGFhUyBtZWNoYW5pc20sIGV2ZW4gd2hlbiBwcmVzZW50ZWQgYSB2YWxpZCBESENQdjQg bGVhc2UuDQo+ID4NCj4gPiAgICAgLVJpY2hhcmQNCj4gPiAgICAgT24gTW9uLCAyOCBNYXkgMjAx OCBhdCAxMDoxMSwgSk9SREkgUEFMRVQgTUFSVElORVoNCj4gPiAgICAgPGpvcmRpLnBhbGV0PTQw Y29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ICAgICA+DQo+ID4gICAg ID4gSGkgQmFyYmFyYSwNCj4gPiAgICAgPg0KPiA+ICAgICA+IFNvcnJ5IHRoZSBsYXRlIGFuc3dl ciwgbGFzdCBmZXcgd2Vla3MgaGFkIGJlZW4gYSBub24tc3RvcCB0cmF2ZWxpbmcgaW4NCj4gMyBj b250aW5lbnRzIGFuZCB0b28gbXVjaCB3b3JrIC4uLg0KPiA+ICAgICA+DQo+ID4gICAgID4gSSBz ZWUgd2hhdCB5b3UgbWVhbiBhbmQgd2UgaGF2ZSBkaXNjdXNzZWQgYWJvdXQgdGhpcyBhbW9uZyB0 aGUNCj4gY29hdXRob3JzIGFuZCBhbWVuZGVkIHRoZSBkb2N1bWVudCwgaW5jbHVkaW5nIHNvbWUg b3RoZXIgY29tbWVudHMNCj4gcmVjZWl2ZWQgaW4gdGhlIGxpc3QuDQo+ID4gICAgID4NCj4gPiAg ICAgPiBUaGUgbmV3IHZlcnNpb24gaGFzIGJlZW4gcHVibGlzaGVkIGEgZmV3IG1pbnV0ZXMgYWdv Og0KPiA+ICAgICA+DQo+ID4gICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJE aWV0Zi0yRHY2b3BzLTJEdHJhbnNpdGlvbi0NCj4gMkRpcHY0YWFzXy0zRmluY2x1ZGUtNUZ0ZXh0 LTNEMSZkPUR3SUdhUSZjPUxGWVotDQo+IG85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4 c2M4U1k4VHE0dnJmb2cmbT00bUxFMzhjYmhHNkliVm5JQ18tSENxLUJxWkMtDQo+IDFRa1dLY0dt TVNXMmVibyZzPUdmcmc1NjF6R1FJYlE0V2pBN2pUVFFnVDd6TmNHZlkxa1E1RUdscTJrTA0KPiBV JmU9DQo+ID4gICAgID4NCj4gPiAgICAgPiBCYXNpY2FsbHksIHdlIGFyZSBrZWVwaW5nIGEgTVVT VCBmb3IgcmV0YWlsIHByb2R1Y3QgdmVyc2lvbnMsIGJ1dCBub3QgZm9yDQo+IHNwZWNpZmljIElT UCB2ZXJzaW9ucy4gSSBob3BlIHlvdSBhZ3JlZSB3aXRoIHRoaXMsIGFzIHdlIGJlbGlldmUgaXQg bWFrZXMNCj4gc2Vuc2UuDQo+ID4gICAgID4NCj4gPiAgICAgPiBXZSBkb24ndCB1cGRhdGUgYW55 bW9yZSB0aGUgUkZDNzA4NCwgYW5kIHdlIGp1c3QgdXNlIHRoZSBzYW1lIHN0eWxlDQo+IHRvIGFk ZCB0aGUgcmVxdWlyZW1lbnRzIGZvciBhbiBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIChhbmQg d2UgdXNlIHRoaXMNCj4gdGVybWlub2xvZ3kgYWNyb3NzIGFsbCB0aGUgZG9jdW1lbnQpLg0KPiA+ ICAgICA+DQo+ID4gICAgID4gVGhlIG1haW4gY2hhbmdlcyBhcmUgc3VtbWFyaXplZCBpbiB0aGUg QW5uZXggQzoNCj4gPiAgICAgPiAxLiAgSUQtTml0czogSUFOQSBzZWN0aW9uLg0KPiA+ICAgICA+ IDIuICBJRC1OaXRzOiBSRkM3MDg0IHJlZmVyZW5jZSByZW1vdmVkIGZyb20gQWJzdHJhY3QuDQo+ ID4gICAgID4gMy4gIFRoaXMgZG9jdW1lbnQgbm8gbG9uZ2VyIHVwZGF0ZXMgUkZDNzA4NC4NCj4g PiAgICAgPiA0LiAgVVBuUCBzZWN0aW9uIHJld29yZGVkLg0KPiA+ICAgICA+IDUuICAiQ0UgUm91 dGVyIiBjaGFuZ2VkIHRvICJJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIi4NCj4gPiAgICAgPiA2 LiAgUmVkdWNlZCB0ZXh0IGluIEFubmV4IEEuDQo+ID4gICAgID4NCj4gPiAgICAgPiBIb3BlZnVs bHkgZXZlcnlib2R5IGFncmVlcyBub3cgd2l0aCB0aGlzIHZlcnNpb24sIGFuZCBpbiBhbnkgY2Fz ZSwgd2lsbA0KPiBiZSB2ZXJ5IGhlbHBmdWwgaWYgd2UgY2FuIGdldCBhbnkgaW5wdXRzLg0KPiA+ ICAgICA+DQo+ID4gICAgID4gUmVnYXJkcywNCj4gPiAgICAgPiBKb3JkaQ0KPiA+ICAgICA+DQo+ ID4gICAgID4NCj4gPiAgICAgPg0KPiA+ICAgICA+IO+7vy0tLS0tTWVuc2FqZSBvcmlnaW5hbC0t LS0tDQo+ID4gICAgID4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBlbiBub21i cmUgZGUgIlNUQVJLLCBCQVJCQVJBDQo+IEgiIDxiczc2NTJAYXR0LmNvbT4NCj4gPiAgICAgPiBG ZWNoYTogbHVuZXMsIDMwIGRlIGFicmlsIGRlIDIwMTgsIDE5OjIwDQo+ID4gICAgID4gUGFyYTog VjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPg0KPiA+ICAgICA+IEFzdW50bzogUmU6IFt2Nm9w c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtDQo+IDAw LnR4dA0KPiA+ICAgICA+DQo+ID4gICAgID4gICAgIEhpIEpvcmRpLA0KPiA+ICAgICA+ICAgICBJ IHdhcyBoYXZpbmcgYSBoYXJkIHRpbWUgdW5kZXJzdGFuZGluZyB3aGVyZSB5b3Ugd2VyZSBoZWFk ZWQgd2l0aA0KPiBwcm9wb3NlZCBjaGFuZ2VzLCBieSBmb2xsb3dpbmcgdGhlIGVtYWlsIHRocmVh ZC4gU28gSSB3YXMgd2FpdGluZyBmb3IgdGhpcw0KPiB1cGRhdGUuIE15IGNvbXBhbnkncyBlbWFp bCBzZXJ2ZXIgYWxzbyByZWZ1c2VzIHRvIGRlbGl2ZXIgdG8gbWUgc29tZQ0KPiBlbWFpbHMgc2Vu dCB0byB0aGlzIGxpc3Qgd2l0aG91dCB0ZWxsaW5nIG1lLiBUaGF0IHByb2JhYmx5IGFkZHMgdG8g bXkgZGlmZmljdWx0eS4NCj4gPiAgICAgPg0KPiA+ICAgICA+ICAgICBNeSBzdWdnZXN0aW9uIHJl bGF0ZWQgdG8gbWFraW5nIHJlcXVpcmVtZW50cyAiTVVTVCIgd2VyZSB0aWVkIHRvDQo+IGFsc28g Km5vdCogbWFraW5nIHRoaXMgYW4gdXBkYXRlIHRvIFJGQyA3MDg0Lg0KPiA+ICAgICA+DQo+ID4g ICAgID4gICAgIEhlcmUgaXMgdGhlIHByb2JsZW06DQo+ID4gICAgID4gICAgIElmIHRoaXMgaXMg YW4gdXBkYXRlIHRvIFJGQyA3MDg0LCB0aGVuIEkgY2Fubm90IHN1cHBvcnQgYW55ICJNVVNUIg0K PiBzdGF0ZW1lbnRzLg0KPiA+ICAgICA+ICAgICBNeSBlbXBsb3llciBtYWtlcyB1c2Ugb2YgUkZD IDcwODQuIEFzIGlzLiBVcGRhdGluZyBSRkMgNzA4NCB3aXRoDQo+IGFkZGl0aW9uYWwgIk1VU1Qi IHN0YXRlbWVudHMgaW1wYWN0cyBteSBlbXBsb3llcidzIGFiaWxpdHkgdG8gdXNlIGFuZA0KPiBy ZWZlcmVuY2UgUkZDIDcwODQgdG8gZ2V0IHRoZSBDRSByb3V0ZXJzIGl0IHdhbnRzLiBBbiBSRkMg NzA4NCB1cGRhdGUgd2l0aA0KPiAiTVVTVCIgc3RhdGVtZW50cyAodGhhdCBhcmUgbm90IG5lZWRl ZCBieSBtYW55IGN1cnJlbnQgZGVwbG95bWVudHMpDQo+IHdvdWxkIGJlIGhhcm1mdWwgdG8gdGhl IGV4aXN0aW5nIElQdjYgZWNvc3lzdGVtLg0KPiA+ICAgICA+DQo+ID4gICAgID4gICAgIEZvciBh IGRldmljZSBwcm9maWxlIHRvIGJlIHVzYWJsZSBieSB0aGUgdmVuZG9yIGFuZCBJU1AgY29tbXVu aXR5LCBpdA0KPiBtdXN0IGNvbnRhaW4gIk1VU1QiIHN0YXRlbWVudHMgZm9yIGFsbCBpdGVtcyB0 aGF0IG5lZWQgdG8gYmUgcmVxdWlyZWQgdG8NCj4gYWNoaWV2ZSB0aGUgcHJvZmlsZSdzIGdvYWwu IFRyeWluZyB0byBnZXQgdmVuZG9ycyB0byBpbXBsZW1lbnQgbG90cyBvZg0KPiAiU0hPVUxEIiBz dGF0ZW1lbnRzIGlzIGZ1dGlsZS4gQXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciwgSSBkbyBu b3Qgc3VwcG9ydA0KPiBJRVRGIHB1Ymxpc2hpbmcgYSBmdXRpbGUgZGV2aWNlIHByb2ZpbGUgZG9j dW1lbnQgd2l0aCBtYW55ICJTSE9VTEQiDQo+IHN0YXRlbWVudHMuDQo+ID4gICAgID4NCj4gPiAg ICAgPiAgICAgVGhlIHNvbHV0aW9uIEkgaGF2ZSBwcm9wb3NlZCBpcyB0byBjcmVhdGUgYSBicmFu ZCBuZXcgZGV2aWNlIHByb2ZpbGUuDQo+IEEgZGV2aWNlIHByb2ZpbGUgZm9yIHNvbWV0aGluZyBj YWxsZWQgYW4gIklQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIiLiBUaGlzDQo+IGRldmljZSBwcm9m aWxlIGlzIG5vdCBhbiB1cGRhdGUgdG8gUkZDIDcwODQuIEl0IGlzIGl0cyBvd24gdGhpbmcuIEl0 IGlzIGZyZWUgdG8NCj4gbWFrZSB1c2Ugb2YgUkZDIDcwODQgYW55IHdheSBpdCB3YW50cyAtLSBu b3QgYXQgYWxsLCBpbiB3aG9sZSwgb3IgYnkNCj4gcmVmZXJlbmNpbmcgc2VjdGlvbnMgaXQgZG9l cyBvciBkb2Vzbid0IHdhbnQgdG8gcmVxdWlyZSBhcyBwYXJ0IG9mIHRoZSAiSVB2Ng0KPiBUcmFu c2l0aW9uIENFIFJvdXRlciIgZGV2aWNlIHByb2ZpbGUuDQo+ID4gICAgID4gICAgIEJhcmJhcmEN Cj4gPiAgICAgPg0KPiA+ICAgICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ICAgICA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiAg ICAgPiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gPiAgICAgPiAgICAgaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZy PUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09NG1MRTM4Y2JoRzZJYlZuSUNfLUhDcS1CcVpD LQ0KPiAxUWtXS2NHbU1TVzJlYm8mcz1JZlJ4WjdwSi0ySS0NCj4gTEk0SWZkYmdrcGFhN0REd2pV SElyZGJXM3JCQjRSYyZlPQ0KPiA+ICAgICA+DQo+ID4gICAgID4NCj4gPiAgICAgPg0KPiA+ICAg ICA+DQo+ID4gICAgID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KPiA+ICAgICA+IElQdjQgaXMgb3Zlcg0KPiA+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9y IHRoZSBuZXcgSW50ZXJuZXQgPw0KPiA+ICAgICA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLQ0KPiAzQV9fd3d3LmNvbnN1bGludGVsLmVzJmQ9RHdJR2FR JmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+IDhzYzhTWThUcTR2cmZv ZyZtPTRtTEUzOGNiaEc2SWJWbklDXy1IQ3EtQnFaQy0NCj4gMVFrV0tjR21NU1cyZWJvJnM9eTdS QkRWZjlUaGY1bkxtSVNqSF92alY5R2ZTTlhUZm5UcVZRakltMktwDQo+IEEmZT0NCj4gPiAgICAg PiBUaGUgSVB2NiBDb21wYW55DQo+ID4gICAgID4NCj4gPiAgICAgPiBUaGlzIGVsZWN0cm9uaWMg bWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZA0KPiBv ciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1 cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBk aXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBl dmVuIGlmDQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYQ0KPiBjcmltaW5hbCBvZmZlbnNl LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55 DQo+IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRl bnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcg YXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gY29uc2lk ZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5h bCBzZW5kZXIgdG8NCj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRl IGl0Lg0KPiA+ICAgICA+DQo+ID4gICAgID4NCj4gPiAgICAgPg0KPiA+ICAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgID4gdjZvcHMg bWFpbGluZyBsaXN0DQo+ID4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiAgICAgPg0KPiA+IGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3 dy5pZXRmLm9yZ19tYWlsDQo+ID4gbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFQNCj4gPiBxNHZyZm9nJm09NG1M RTM4Y2JoRzZJYlZuSUNfLUhDcS1CcVpDLQ0KPiAxUWtXS2NHbU1TVzJlYm8mcz1JZlJ4WjdwSi0y SS1MSQ0KPiA+IDRJZmRiZ2twYWE3RER3alVISXJkYlczckJCNFJjJmU9DQo+ID4NCj4gPiAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgICAg djZvcHMgbWFpbGluZyBsaXN0DQo+ID4gICAgIHY2b3BzQGlldGYub3JnDQo+ID4NCj4gPiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cu aWV0Zi5vcmdfbWFpbA0KPiA+IG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUdhUSZjPUxGWVotbzlf SFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+IDhzYzhTWThUDQo+ID4gcTR2cmZvZyZtPTRtTEUz OGNiaEc2SWJWbklDXy1IQ3EtQnFaQy0NCj4gMVFrV0tjR21NU1cyZWJvJnM9SWZSeFo3cEotMkkt TEkNCj4gPiA0SWZkYmdrcGFhN0REd2pVSElyZGJXM3JCQjRSYyZlPQ0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K PiA+IElQdjQgaXMgb3Zlcg0KPiA+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQg Pw0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLQ0K PiAzQV9fd3d3LmNvbnN1bGludGVsLmVzDQo+ID4gJmQ9RHdJR2FRJmM9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09NG1MRTM4Y2INCj4gPiBoRzZJ YlZuSUNfLUhDcS1CcVpDLQ0KPiAxUWtXS2NHbU1TVzJlYm8mcz15N1JCRFZmOVRoZjVuTG1JU2pI X3ZqVjlHZlNOWFRmbg0KPiA+IFRxVlFqSW0yS3BBJmU9DQo+ID4gVGhlIElQdjYgQ29tcGFueQ0K PiA+DQo+ID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hp Y2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24g aXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlk dWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQg ZGlzY2xvc3VyZSwNCj4gY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZg0KPiBwYXJ0aWFsbHksIGluY2x1ZGluZyBh dHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRl cmVkIGENCj4gY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueQ0KPiBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLA0KPiBldmVu IGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLCB3aWxsIGJlDQo+IGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3Ug bXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvDQo+IGluZm9ybSBhYm91dCB0aGlz IGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWwNCj4gPiBt YW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9H emhDLQ0KPiA4c2M4U1k4VA0KPiA+IHE0dnJmb2cmbT00bUxFMzhjYmhHNkliVm5JQ18tSENxLUJx WkMtDQo+IDFRa1dLY0dtTVNXMmVibyZzPUlmUnhaN3BKLTJJLUxJDQo+ID4gNElmZGJna3BhYTdE RHdqVUhJcmRiVzNyQkI0UmMmZT0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9y Zw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUdhUSZjPUxGWVot DQo+IG85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4c2M4U1k4VHE0dnJmb2cmbT00bUxF MzhjYmhHNkliVm5JQ18tSENxLUJxWkMtDQo+IDFRa1dLY0dtTVNXMmVibyZzPUlmUnhaN3BKLTJJ LQ0KPiBMSTRJZmRiZ2twYWE3RER3alVISXJkYlczckJCNFJjJmU9DQo= From nobody Wed Jun 6 06:41: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 27F01130F43 for ; Wed, 6 Jun 2018 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4MkYTBf4W-u for ; Wed, 6 Jun 2018 06:41:06 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC19B130F1E for ; Wed, 6 Jun 2018 06:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528292463; x=1528897263; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=yMxXQohq +t4cjI9kjlvOcz6SGrouhYpFEaE53pnlRjw=; b=DsswEI3lnJRvb51YxxRVKm2X XXbVJWtWarstF7lvOrfE5zXieAM7kpf78ntswLywOFcaIVj58zfTTwO229MrSXqI 9LXncCFJ8s3tjT1GRKe2SX8/xjX1bAigBZigJxkRWqByTq+9WB+4oQG5cShH3Uxo 8vk+34p+ZubLh0XH2Es= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 15:41:03 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 15:41:02 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783234.msg for ; Wed, 06 Jun 2018 15:41:02 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 15:41:02 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 15:41:01 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 13:41:24 -0000 Below in-line. =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Richard Patterson Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:55 Para: "v6ops@ietf.org list" , Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt At the moment the current wording overrides the presence of DHCPv6 S46 Options, this prevents the ISP from doing a per-subscriber granular migration. eg. by including it within a RADIUS Access-Accept Attribute or not. =20 Disabling of the DHCPv4 server forces a big bang migration strategy; The ISP may not have the luxury to upgrade all the CPE types on the network to ones that support IPv4aaS method, so a big bang migration wouldn't be feasible. If you stop DHCPv4/PPP for specific customers, you have the same per-subscr= iber control, right ? =20 Regarding the quality argument, this makes the assumption that all IPv4aaS methods mentioned are worse than native IPv4. There's no qualification on if that native IPv4 is actually behind NAT444 or not. I'd say that if the ISP is returning valid S46 Options, then they want or even expect the client to make use of them, not ignore them. Yeah, if you compare the quality of IPv4 with NAT444. The problem I see if we change this behavior is that S46 only provides a so= lution for some of the transition mechanism, not all, so for example, 464XL= AT will not be able to work if we don't follow the current suggested approa= ch. =20 -Richard On Wed, 6 Jun 2018 at 13:34, JORDI PALET MARTINEZ wrote: > > Hi Richard, > > This is an interesting perspective ... > > What we prefer "the best quality" that dual-stack can offer, or even = if you have lower quality, "push for IPv6" ? > > Would not be better that if your network is offering already IPv4-as-= a-service, you stop DHCPv4/PPP ? > > I think that way, you, the ISP, have a better control for those custo= mers that you want to provide "native-IPv4" vs transition. > > I will like to heard what other people believes about this. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Richard Patterson > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:26 > Para: "v6ops@ietf.org list" , > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 0.txt > > Hi Jordi, > > I'm not sure that I agree with requirement TRANS-2: > "The IPv6 Transition CE Router MUST verify if the WAN link suppor= ts > native IPv4. In that case, transition mechanisms SHOULD NOT be > automatically enabled for that interface." > > In fact I'd suggest the exact opposite, if a CE Router receives v= alid > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operation= s > until the WAN link status changes. This could be expanded to inc= lude > a validation of a working IPv4aaS, but unsure how that should loo= k. > For example, a brownfield IPv4aaS deployment is likely to still b= e > running dual stack in parallel whilst it migrates its clients to > IPv4aaS, the current wording would hinder this migration, by > preferring to stay on native (or NAT444) IPv4. > > The "suspend" could also be debated, that it could be sufficient = to > rely on the DHCPv4 back off mechanisms, but on a large network th= at > could still put a lot of extra load on the DHCPv4 server/relay an= d > RADIUS. My vote is to suspend temporarily until reboot/WAN chan= ge. > > And anecdotally, the current behaviour of OpenWRT is to prefer th= e S46 > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. > > -Richard > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > wrote: > > > > Hi Barbara, > > > > Sorry the late answer, last few weeks had been a non-stop trave= ling in 3 continents and too much work ... > > > > I see what you mean and we have discussed about this among the = coauthors and amended the document, including some other comments received = in the list. > > > > The new version has been published a few minutes ago: > > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ip= v4aas/?include_text=3D1 > > > > Basically, we are keeping a MUST for retail product versions, b= ut not for specific ISP versions. I hope you agree with this, as we believe= it makes sense. > > > > We don't update anymore the RFC7084, and we just use the same s= tyle to add the requirements for an IPv6 Transition CE Router (and we use t= his terminology across all the document). > > > > The main changes are summarized in the Annex C: > > 1. ID-Nits: IANA section. > > 2. ID-Nits: RFC7084 reference removed from Abstract. > > 3. This document no longer updates RFC7084. > > 4. UPnP section reworded. > > 5. "CE Router" changed to "IPv6 Transition CE Router". > > 6. Reduced text in Annex A. > > > > Hopefully everybody agrees now with this version, and in any ca= se, will be very helpful if we can get any inputs. > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: v6ops en nombre de "STARK, BARBARA= H" > > Fecha: lunes, 30 de abril de 2018, 19:20 > > Para: V6 Ops List > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv= 4aas-00.txt > > > > Hi Jordi, > > I was having a hard time understanding where you were heade= d with proposed changes, by following the email thread. So I was waiting fo= r this update. My company's email server also refuses to deliver to me some= emails sent to this list without telling me. That probably adds to my diff= iculty. > > > > My suggestion related to making requirements "MUST" were ti= ed to also *not* making this an update to RFC 7084. > > > > Here is the problem: > > If this is an update to RFC 7084, then I cannot support any= "MUST" statements. > > My employer makes use of RFC 7084. As is. Updating RFC 7084= with additional "MUST" statements impacts my employer's ability to use and= reference RFC 7084 to get the CE routers it wants. An RFC 7084 update with= "MUST" statements (that are not needed by many current deployments) would = be harmful to the existing IPv6 ecosystem. > > > > For a device profile to be usable by the vendor and ISP com= munity, it must contain "MUST" statements for all items that need to be req= uired to achieve the profile's goal. Trying to get vendors to implement lot= s of "SHOULD" statements is futile. As an individual contributor, I do not = support IETF publishing a futile device profile document with many "SHOULD"= statements. > > > > The solution I have proposed is to create a brand new devic= e profile. A device profile for something called an "IPv6 Transition CE Rou= ter". This device profile is not an update to RFC 7084. It is its own thing= . It is free to make use of RFC 7084 any way it wants -- not at all, in who= le, or by referencing sections it does or doesn't want to require as part o= f the "IPv6 Transition CE Router" device profile. > > Barbara > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged or confidential. The information is intended to be for the exclusive = use of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this informatio= n, even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense. If you are not the intended recipien= t be aware that any disclosure, copying, distribution or use of the content= s of this information, even if partially, including attached files, is stri= ctly prohibited, will be considered a criminal offense, so you must reply t= o the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > 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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 06:49: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 EB4EB130F1E for ; Wed, 6 Jun 2018 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbVYu_fxSG4H for ; Wed, 6 Jun 2018 06:49:42 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CCC130F1D for ; Wed, 6 Jun 2018 06:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528292980; x=1528897780; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=9RXkSC8T iEjqP0CJpeC9wGpmU+UUa39cVkTkoESopRs=; b=mdx0eDhl7iCe6KGxMQ8vQymm biQgLnR1VGq7yl0opRC9ykF3aryQ1ZjsdjsKpt0YtM96lA4Kw6qiV+OO1JfMFMk4 DgE2jFe8gyWo8NB26Xi1z1jI7iEJsTZOD5tYjxCUwjXpNmwWkKj+Di28davOOeas AH2S+B/M6ZlphO0bfcE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 15:49:40 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 15:49:39 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783240.msg for ; Wed, 06 Jun 2018 15:49:37 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 15:49:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 15:49:37 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Richard Patterson' , "v6ops@ietf.org list" Message-ID: <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 13:49:50 -0000 I see now the point, if you have already dual-stack ...=20 I think this (removing TRANS-2) may work then: General transition requirements: TRANS-1: If more than one S46 mechanism is supported, the IPv6 Transition CE Router MUST support the DHCPv6 S46 priority option described in [RFC8026] (Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism). TRANS-2: If 464XLAT [RFC6877] is supported, the IPv6 Transition CE Router MUST enable the CLAT (in order to automatically configure 464XLAT [RFC6877]). If 464XLAT [RFC6877] is not supported, and more than one S46 mechanism is supported, following Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which will allow configuring any of the other transition mechanisms. If we agree on this text, I can upload a new version with this change in a = couple of days, unless there are new inputs in this part or others ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 15:41 Para: 'Richard Patterson' , "v6ops@ietf.org list" , "jordi.palet=3D40consulintel.es@dmarc.ietf.org" Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt > At the moment the current wording overrides the presence of DHCPv6 S4= 6 > Options, this prevents the ISP from doing a per-subscriber granular > migration. eg. by including it within a RADIUS Access-Accept Attribut= e or not. >=20 > Disabling of the DHCPv4 server forces a big bang migration strategy; = The ISP > may not have the luxury to upgrade all the CPE types on the network t= o ones > that support IPv4aaS method, so a big bang migration wouldn't be feas= ible. >=20 > Regarding the quality argument, this makes the assumption that all IP= v4aaS > methods mentioned are worse than native IPv4. There's no qualificati= on on > if that native IPv4 is actually behind NAT444 or not. > I'd say that if the ISP is returning valid S46 Options, then they wan= t or even > expect the client to make use of them, not ignore them. >=20 > -Richard =20 I think I agree with Richard on this. If an ISP already has dual stack = deployed and is starting deployment of an IPv4aaS technology, or has simult= aneously deployed dual stack with IPv4aaS, then the goal must clearly be to= move people to the IPv4aaS technology. If an ISP has IPv4aaS deployed, it = is highly unlikely they will then deploy dual stack. So the presence of bot= h dual stack and IPv4aaS must be an indication the ISP wants to move people= off dual stack and onto IPv4aaS. =20 IPv4aaS should be the preferred connection in this case, in order to ac= hieve a smoother transition. Note that IPv6 wasn't always "better" than IPv= 4 (it often had higher latency), but we still all agreed it should be "pref= erred". I think this is the same. Barbara =20 =20 > On Wed, 6 Jun 2018 at 13:34, JORDI PALET MARTINEZ > wrote: > > > > Hi Richard, > > > > This is an interesting perspective ... > > > > What we prefer "the best quality" that dual-stack can offer, or eve= n if you > have lower quality, "push for IPv6" ? > > > > Would not be better that if your network is offering already IPv4-a= s-a- > service, you stop DHCPv4/PPP ? > > > > I think that way, you, the ISP, have a better control for those cus= tomers > that you want to provide "native-IPv4" vs transition. > > > > I will like to heard what other people believes about this. > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: v6ops en nombre de Richard Patterson > > > > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:26 > > Para: "v6ops@ietf.org list" , > > > > Asunto: Re: [v6ops] I-D Action: > > draft-ietf-v6ops-transition-ipv4aas-00.txt > > > > Hi Jordi, > > > > I'm not sure that I agree with requirement TRANS-2: > > "The IPv6 Transition CE Router MUST verify if the WAN link supp= orts > > native IPv4. In that case, transition mechanisms SHOULD NOT be > > automatically enabled for that interface." > > > > In fact I'd suggest the exact opposite, if a CE Router receives= valid > > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operati= ons > > until the WAN link status changes. This could be expanded to i= nclude > > a validation of a working IPv4aaS, but unsure how that should l= ook. > > For example, a brownfield IPv4aaS deployment is likely to still= be > > running dual stack in parallel whilst it migrates its clients t= o > > IPv4aaS, the current wording would hinder this migration, by > > preferring to stay on native (or NAT444) IPv4. > > > > The "suspend" could also be debated, that it could be sufficien= t to > > rely on the DHCPv4 back off mechanisms, but on a large network = that > > could still put a lot of extra load on the DHCPv4 server/relay = and > > RADIUS. My vote is to suspend temporarily until reboot/WAN ch= ange. > > > > And anecdotally, the current behaviour of OpenWRT is to prefer = the S46 > > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. > > > > -Richard > > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > > wrote: > > > > > > Hi Barbara, > > > > > > Sorry the late answer, last few weeks had been a non-stop tra= veling in > 3 continents and too much work ... > > > > > > I see what you mean and we have discussed about this among th= e > coauthors and amended the document, including some other comments > received in the list. > > > > > > The new version has been published a few minutes ago: > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dtransition- > 2Dipv4aas_-3Finclude-5Ftext-3D1&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DGfrg561zGQIbQ4WjA7jTTQgT7zNcGfY1kQ5EGlq2kL > U&e=3D > > > > > > Basically, we are keeping a MUST for retail product versions,= but not for > specific ISP versions. I hope you agree with this, as we believe it m= akes > sense. > > > > > > We don't update anymore the RFC7084, and we just use the same= style > to add the requirements for an IPv6 Transition CE Router (and we use = this > terminology across all the document). > > > > > > The main changes are summarized in the Annex C: > > > 1. ID-Nits: IANA section. > > > 2. ID-Nits: RFC7084 reference removed from Abstract. > > > 3. This document no longer updates RFC7084. > > > 4. UPnP section reworded. > > > 5. "CE Router" changed to "IPv6 Transition CE Router". > > > 6. Reduced text in Annex A. > > > > > > Hopefully everybody agrees now with this version, and in any = case, will > be very helpful if we can get any inputs. > > > > > > Regards, > > > Jordi > > > > > > > > > > > > =EF=BB=BF-----Mensaje original----- > > > De: v6ops en nombre de "STARK, BARBA= RA > H" > > > Fecha: lunes, 30 de abril de 2018, 19:20 > > > Para: V6 Ops List > > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-i= pv4aas- > 00.txt > > > > > > Hi Jordi, > > > I was having a hard time understanding where you were hea= ded with > proposed changes, by following the email thread. So I was waiting for= this > update. My company's email server also refuses to deliver to me some > emails sent to this list without telling me. That probably adds to my= difficulty. > > > > > > My suggestion related to making requirements "MUST" were = tied to > also *not* making this an update to RFC 7084. > > > > > > Here is the problem: > > > If this is an update to RFC 7084, then I cannot support a= ny "MUST" > statements. > > > My employer makes use of RFC 7084. As is. Updating RFC 70= 84 with > additional "MUST" statements impacts my employer's ability to use and > reference RFC 7084 to get the CE routers it wants. An RFC 7084 update= with > "MUST" statements (that are not needed by many current deployments) > would be harmful to the existing IPv6 ecosystem. > > > > > > For a device profile to be usable by the vendor and ISP c= ommunity, it > must contain "MUST" statements for all items that need to be required= to > achieve the profile's goal. Trying to get vendors to implement lots o= f > "SHOULD" statements is futile. As an individual contributor, I do not= support > IETF publishing a futile device profile document with many "SHOULD" > statements. > > > > > > The solution I have proposed is to create a brand new dev= ice profile. > A device profile for something called an "IPv6 Transition CE Router".= This > device profile is not an update to RFC 7084. It is its own thing. It = is free to > make use of RFC 7084 any way it wants -- not at all, in whole, or by > referencing sections it does or doesn't want to require as part of th= e "IPv6 > Transition CE Router" device profile. > > > Barbara > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I- > LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.consulintel.es&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3Dy7RBDVf9Thf5nLmISjH_vjV9GfSNXTfnTqVQjIm2Kp > A&e=3D > > > The IPv6 Company > > > > > > This electronic message contains information which may be pri= vileged > or confidential. The information is intended to be for the exclusive = use of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be considered a > criminal offense. If you are not the intended recipient be aware that= any > disclosure, copying, distribution or use of the contents of this info= rmation, > even if partially, including attached files, is strictly prohibited, = will be > considered a criminal offense, so you must reply to the original send= er to > inform about this communication and delete it. > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC= - > 8sc8SY8T > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC= - > 8sc8SY8T > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.consulintel.es > > &d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D4mLE38cb > > hG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3Dy7RBDVf9Thf5nLmISjH_vjV9GfSNXTfn > > TqVQjIm2KpA&e=3D > > The IPv6 Company > > > > This electronic message contains information which may be privilege= d or > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be considered a > criminal offense. If you are not the intended recipient be aware that= any > disclosure, copying, distribution or use of the contents of this info= rmation, > even if partially, including attached files, is strictly prohibited, = will be > considered a criminal offense, so you must reply to the original send= er to > inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC= - > 8sc8SY8T > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I- > LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 07:41:32 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 F149E130E31 for ; Wed, 6 Jun 2018 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 s-xt3tLA0XT2 for ; Wed, 6 Jun 2018 07:41:18 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE0C130F3A for ; Wed, 6 Jun 2018 07:41:18 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 76-v6so8454249itx.4 for ; Wed, 06 Jun 2018 07:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6g88gCbhD+EAHzz1aCRmHwuynichsl+9pPDDPd768QA=; b=VJcUp4hAoFMVBmbLWxp3JD2Lb2NuRzHqKutac2pIOqVe416sEn3d7O3Ne+0BLxHr5x zOyg5CoVJDKL/AnrTCE3unNwkE8/0P9iWQ6jBxTts6OAHMs0EofNnnvD0nllk2s3Roo4 3XWGPy6K/DdjDE55h1cy/WOlxFzwvNLJsfLykyTeUK5laOJD15M1GM8DweAqGtAMj1Kr T3duVBbYySPPUIo2DOb4UjKw05PQcoywtPgzNoTQrxVnyOcMd+hD7klKbGGGTCh0g/Lc 6st5EsfoUZx/P0EgFaHcSGuDDij9JNB8PplSvRKeYTJiXxbAsfDavogj2oU0Y6g/C6gJ WgDA== 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:content-transfer-encoding; bh=6g88gCbhD+EAHzz1aCRmHwuynichsl+9pPDDPd768QA=; b=cFk9CNEaZkbI2i/QAJGZ3RSJKb4YczlklFh8cVUf+tos37an66KdJAYwK2VsTgU7fy GHI23YsDH+9XIRN/4BvxuV9FZAzq71OW2iEZ3UdVDECAGHz1KO6LFYb5L60EKGJUbz54 zcmTpeVX1Wicd+GDc5RBVWyQWZmly0QcDmR2uJha4K2MChg7Re14dhUPIkH/XFWNao5E odJPYu9XzP+aueuJwp1ojVaQBWzIvKSUvTh9f6WjFsYx86ojhKG15N40DVsG0Ab49Gau cVKCYNTQbhvi6TemEQTqAvkKxDUXevIJvb6ylj4gpXSquEX2vuc5rDmOlbf8uU0dH+U4 FnKw== X-Gm-Message-State: APt69E3sofIswOo76FjoZYmRXQANZJeCttESwW2XYmUo3RM2LIZjNYSR Xc5O+9IgEmt5KPw1n48z4qnoZmJN X-Google-Smtp-Source: ADUXVKLtoO1bMA3AETV8V4lpcWygifioZBTEc8rw3NoDYNLvNJQvjZplKXDOaWG8+/pni3+RE+ywZA== X-Received: by 2002:a24:ed4a:: with SMTP id r71-v6mr2908110ith.53.1528296077746; Wed, 06 Jun 2018 07:41:17 -0700 (PDT) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com. [209.85.214.48]) by smtp.gmail.com with ESMTPSA id t123-v6sm1849546itb.20.2018.06.06.07.41.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 07:41:16 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id l6-v6so8352608iti.2 for ; Wed, 06 Jun 2018 07:41:16 -0700 (PDT) X-Received: by 2002:a24:8046:: with SMTP id g67-v6mr2838697itd.16.1528296076436; Wed, 06 Jun 2018 07:41:16 -0700 (PDT) MIME-Version: 1.0 References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> In-Reply-To: <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> From: Richard Patterson Date: Wed, 6 Jun 2018 15:41:05 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , JORDI PALET MARTINEZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:41:27 -0000 That would address my concern. On Wed, 6 Jun 2018 at 14:49, JORDI PALET MARTINEZ wrote: > > I see now the point, if you have already dual-stack ... > > I think this (removing TRANS-2) may work then: > > > General transition requirements: > > TRANS-1: If more than one S46 mechanism is supported, the IPv6 > Transition CE Router MUST support the DHCPv6 S46 priority > option described in [RFC8026] (Unified IPv4-in-IPv6 > Softwire Customer Premises Equipment (CPE): A DHCPv6-Based > Prioritization Mechanism). > > TRANS-2: If 464XLAT [RFC6877] is > supported, the IPv6 Transition CE Router MUST enable the > CLAT (in order to automatically configure 464XLAT > [RFC6877]). If 464XLAT [RFC6877] is not supported, and > more than one S46 mechanism is supported, following > Section 1.4 of [RFC8026], MUST check for a valid match in > OPTION_S46_PRIORITY, which will allow configuring any of > the other transition mechanisms. > > > If we agree on this text, I can upload a new version with this change in = a couple of days, unless there are new inputs in this part or others ... > > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de "STARK, BARBARA H" > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 15:41 > Para: 'Richard Patterson' , "v6ops@ietf.org list" <= v6ops@ietf.org>, "jordi.palet=3D40consulintel.es@dmarc.ietf.org" > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.tx= t > > > At the moment the current wording overrides the presence of DHCPv6 = S46 > > Options, this prevents the ISP from doing a per-subscriber granular > > migration. eg. by including it within a RADIUS Access-Accept Attrib= ute or not. > > > > Disabling of the DHCPv4 server forces a big bang migration strategy= ; The ISP > > may not have the luxury to upgrade all the CPE types on the network= to ones > > that support IPv4aaS method, so a big bang migration wouldn't be fe= asible. > > > > Regarding the quality argument, this makes the assumption that all = IPv4aaS > > methods mentioned are worse than native IPv4. There's no qualifica= tion on > > if that native IPv4 is actually behind NAT444 or not. > > I'd say that if the ISP is returning valid S46 Options, then they w= ant or even > > expect the client to make use of them, not ignore them. > > > > -Richard > > I think I agree with Richard on this. If an ISP already has dual stac= k deployed and is starting deployment of an IPv4aaS technology, or has simu= ltaneously deployed dual stack with IPv4aaS, then the goal must clearly be = to move people to the IPv4aaS technology. If an ISP has IPv4aaS deployed, i= t is highly unlikely they will then deploy dual stack. So the presence of b= oth dual stack and IPv4aaS must be an indication the ISP wants to move peop= le off dual stack and onto IPv4aaS. > > IPv4aaS should be the preferred connection in this case, in order to = achieve a smoother transition. Note that IPv6 wasn't always "better" than I= Pv4 (it often had higher latency), but we still all agreed it should be "pr= eferred". I think this is the same. > Barbara > > > > On Wed, 6 Jun 2018 at 13:34, JORDI PALET MARTINEZ > > wrote: > > > > > > Hi Richard, > > > > > > This is an interesting perspective ... > > > > > > What we prefer "the best quality" that dual-stack can offer, or e= ven if you > > have lower quality, "push for IPv6" ? > > > > > > Would not be better that if your network is offering already IPv4= -as-a- > > service, you stop DHCPv4/PPP ? > > > > > > I think that way, you, the ISP, have a better control for those c= ustomers > > that you want to provide "native-IPv4" vs transition. > > > > > > I will like to heard what other people believes about this. > > > > > > Regards, > > > Jordi > > > > > > > > > > > > =EF=BB=BF-----Mensaje original----- > > > De: v6ops en nombre de Richard Patterson > > > > > > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 14:26 > > > Para: "v6ops@ietf.org list" , > > > > > > Asunto: Re: [v6ops] I-D Action: > > > draft-ietf-v6ops-transition-ipv4aas-00.txt > > > > > > Hi Jordi, > > > > > > I'm not sure that I agree with requirement TRANS-2: > > > "The IPv6 Transition CE Router MUST verify if the WAN link su= pports > > > native IPv4. In that case, transition mechanisms SHOULD NOT = be > > > automatically enabled for that interface." > > > > > > In fact I'd suggest the exact opposite, if a CE Router receiv= es valid > > > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP opera= tions > > > until the WAN link status changes. This could be expanded to= include > > > a validation of a working IPv4aaS, but unsure how that should= look. > > > For example, a brownfield IPv4aaS deployment is likely to sti= ll be > > > running dual stack in parallel whilst it migrates its clients= to > > > IPv4aaS, the current wording would hinder this migration, by > > > preferring to stay on native (or NAT444) IPv4. > > > > > > The "suspend" could also be debated, that it could be suffici= ent to > > > rely on the DHCPv4 back off mechanisms, but on a large networ= k that > > > could still put a lot of extra load on the DHCPv4 server/rela= y and > > > RADIUS. My vote is to suspend temporarily until reboot/WAN = change. > > > > > > And anecdotally, the current behaviour of OpenWRT is to prefe= r the S46 > > > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. > > > > > > -Richard > > > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > > > wrote: > > > > > > > > Hi Barbara, > > > > > > > > Sorry the late answer, last few weeks had been a non-stop t= raveling in > > 3 continents and too much work ... > > > > > > > > I see what you mean and we have discussed about this among = the > > coauthors and amended the document, including some other comments > > received in the list. > > > > > > > > The new version has been published a few minutes ago: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dtransition- > > 2Dipv4aas_-3Finclude-5Ftext-3D1&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DGfrg561zGQIbQ4WjA7jTTQgT7zNcGfY1kQ5EGlq2kL > > U&e=3D > > > > > > > > Basically, we are keeping a MUST for retail product version= s, but not for > > specific ISP versions. I hope you agree with this, as we believe it= makes > > sense. > > > > > > > > We don't update anymore the RFC7084, and we just use the sa= me style > > to add the requirements for an IPv6 Transition CE Router (and we us= e this > > terminology across all the document). > > > > > > > > The main changes are summarized in the Annex C: > > > > 1. ID-Nits: IANA section. > > > > 2. ID-Nits: RFC7084 reference removed from Abstract. > > > > 3. This document no longer updates RFC7084. > > > > 4. UPnP section reworded. > > > > 5. "CE Router" changed to "IPv6 Transition CE Router". > > > > 6. Reduced text in Annex A. > > > > > > > > Hopefully everybody agrees now with this version, and in an= y case, will > > be very helpful if we can get any inputs. > > > > > > > > Regards, > > > > Jordi > > > > > > > > > > > > > > > > =EF=BB=BF-----Mensaje original----- > > > > De: v6ops en nombre de "STARK, BAR= BARA > > H" > > > > Fecha: lunes, 30 de abril de 2018, 19:20 > > > > Para: V6 Ops List > > > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition= -ipv4aas- > > 00.txt > > > > > > > > Hi Jordi, > > > > I was having a hard time understanding where you were h= eaded with > > proposed changes, by following the email thread. So I was waiting f= or this > > update. My company's email server also refuses to deliver to me som= e > > emails sent to this list without telling me. That probably adds to = my difficulty. > > > > > > > > My suggestion related to making requirements "MUST" wer= e tied to > > also *not* making this an update to RFC 7084. > > > > > > > > Here is the problem: > > > > If this is an update to RFC 7084, then I cannot support= any "MUST" > > statements. > > > > My employer makes use of RFC 7084. As is. Updating RFC = 7084 with > > additional "MUST" statements impacts my employer's ability to use a= nd > > reference RFC 7084 to get the CE routers it wants. An RFC 7084 upda= te with > > "MUST" statements (that are not needed by many current deployments) > > would be harmful to the existing IPv6 ecosystem. > > > > > > > > For a device profile to be usable by the vendor and ISP= community, it > > must contain "MUST" statements for all items that need to be requir= ed to > > achieve the profile's goal. Trying to get vendors to implement lots= of > > "SHOULD" statements is futile. As an individual contributor, I do n= ot support > > IETF publishing a futile device profile document with many "SHOULD" > > statements. > > > > > > > > The solution I have proposed is to create a brand new d= evice profile. > > A device profile for something called an "IPv6 Transition CE Router= ". This > > device profile is not an update to RFC 7084. It is its own thing. I= t is free to > > make use of RFC 7084 any way it wants -- not at all, in whole, or b= y > > referencing sections it does or doesn't want to require as part of = the "IPv6 > > Transition CE Router" device profile. > > > > Barbara > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I- > > LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > > > > > > > > > > > > > > > > > ********************************************** > > > > IPv4 is over > > > > Are you ready for the new Internet ? > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > 3A__www.consulintel.es&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3Dy7RBDVf9Thf5nLmISjH_vjV9GfSNXTfnTqVQjIm2Kp > > A&e=3D > > > > The IPv6 Company > > > > > > > > This electronic message contains information which may be p= rivileged > > or confidential. The information is intended to be for the exclusiv= e use of the > > individual(s) named above and further non-explicilty authorized dis= closure, > > copying, distribution or use of the contents of this information, e= ven if > > partially, including attached files, is strictly prohibited and wil= l be considered a > > criminal offense. If you are not the intended recipient be aware th= at any > > disclosure, copying, distribution or use of the contents of this in= formation, > > even if partially, including attached files, is strictly prohibited= , will be > > considered a criminal offense, so you must reply to the original se= nder to > > inform about this communication and delete it. > > > > > > > > > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mail > > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGz= hC- > > 8sc8SY8T > > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mail > > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGz= hC- > > 8sc8SY8T > > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > 3A__www.consulintel.es > > > &d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D4mLE38cb > > > hG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3Dy7RBDVf9Thf5nLmISjH_vjV9GfSNXTfn > > > TqVQjIm2KpA&e=3D > > > The IPv6 Company > > > > > > This electronic message contains information which may be privile= ged or > > confidential. The information is intended to be for the exclusive u= se of the > > individual(s) named above and further non-explicilty authorized dis= closure, > > copying, distribution or use of the contents of this information, e= ven if > > partially, including attached files, is strictly prohibited and wil= l be considered a > > criminal offense. If you are not the intended recipient be aware th= at any > > disclosure, copying, distribution or use of the contents of this in= formation, > > even if partially, including attached files, is strictly prohibited= , will be > > considered a criminal offense, so you must reply to the original se= nder to > > inform about this communication and delete it. > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mail > > > man_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGz= hC- > > 8sc8SY8T > > > q4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I-LI > > > 4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3D4mLE38cbhG6IbVnIC_-HCq-BqZC- > > 1QkWKcGmMSW2ebo&s=3DIfRxZ7pJ-2I- > > LI4Ifdbgkpaa7DDwjUHIrdbW3rBB4Rc&e=3D > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > From nobody Wed Jun 6 07:49:28 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 C70C2130E31 for ; Wed, 6 Jun 2018 07:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqrxgoL3TtIm for ; Wed, 6 Jun 2018 07:49:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAA4130DCA for ; Wed, 6 Jun 2018 07:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528296559; x=1528901359; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=X/BaQmtH 3dLoXGT/jqsXkXWNv98zrktfRVopaJZJyPc=; b=E0KiFd2H68rJLamPRB+7s/2Q i++x5KrBBe1xrW44eiYqOL6tf6dcGeKCJgOHWt0rvyJW861rGZpaXYr86lyenpvU aWx5IP5j2SOkZMnw6jbMoI+36VqddEIndKyTpw/HP+vV4DJKDbWB0fNvuiYs2XQk 9nLGLUb4n7y7N5ZlKGA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 16:49:19 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 16:49:18 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783274.msg for ; Wed, 06 Jun 2018 16:49:18 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 16:49:18 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 16:49:13 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , "v6ops@ietf.org list" Message-ID: <5A741202-FAB8-4785-A624-28D62650FB1C@consulintel.es> Thread-Topic: transition-ipv4aas-01: 464XLAT and NAT References: <2D09D61DDFA73D4C884805CC7865E6114DDD528A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD528A@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] transition-ipv4aas-01: 464XLAT and NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:49:27 -0000 Hi Barbara, It is following section 6.3 of RFC6877 (464XLAT). It is true that RFC8273 is much more recent, and obviously it was not consi= dered, but in a quick consideration I think it is a very complex scenario, = if you're using DHCPv6-PD to also use RFC8273 ... It may be possible, but I'm not completely sure if you are thinking in some= specific scenario that I don't see right now? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 16:44 Para: 'JORDI PALET MARTINEZ' , "v6ops@ietf.org = list" Asunto: transition-ipv4aas-01: 464XLAT and NAT I see: 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Networ= k Address Translation (NAT) on IPv4 traffic translated using the CLAT, unless a dedicated /64 prefix has been acquired using DHCPv6-PD [RFC3633] (IPv6 Prefix Options for DHCPv6). and am curious why the dedicated /64 prefix exclusion applies only to a= prefix acquired by IA_PD, and not one acquired by RFC 8273?=20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 08:22: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 8458F130FA6 for ; Wed, 6 Jun 2018 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8_fvU2DJHE8 for ; Wed, 6 Jun 2018 08:22:07 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F44130F89 for ; Wed, 6 Jun 2018 08:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528298524; x=1528903324; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=s2hh1Wws 3gJyVls5H0DhZ17k4VJfGzUEmpZuDW/QGqE=; b=pRWCMIanaOpitXYdEJICkwXM /i1k5WHWrvVJN5l04AhRUnMfYVal0z85HWf+kYZ6EhYfXSJCi2ZrMSou0lKueMzU E975n8BzVv7a9gADp3tinlMkuRlIEWSMxkzCA1DdI9YXqROcHMLJqWOrumyw19Go 63LOxH0F4OiYpE/Wq10= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 17:22:04 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 17:22:04 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783291.msg for ; Wed, 06 Jun 2018 17:22:03 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 17:22:03 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 17:21:59 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , "v6ops@ietf.org list" Message-ID: <8CB5274B-4221-4692-A6B8-FEDA9ED0A43D@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD531A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD531A@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 15:22:16 -0000 > TRANS-2: If 464XLAT [RFC6877] is > supported, the IPv6 Transition CE Router MUST enable the > CLAT (in order to automatically configure 464XLAT > [RFC6877]). If 464XLAT [RFC6877] is not supported, and > more than one S46 mechanism is supported, following > Section 1.4 of [RFC8026], MUST check for a valid match in > OPTION_S46_PRIORITY, which will allow configuring any of > the other transition mechanisms. I think the comingling of "supported" and "enabled" is problematic in this requirement. "Supported" means (to most people) the same as "implemented". That is, the code exists. "Enabled" means the supported code is actually running. Just because 464XLAT is supported does not mean it is enabled. If 464XLAT is not enabled, then it may not be a good idea to automatically enable CLAT. And, likewise, the other mechanisms should only be configured if they are enabled and not merely supported. I suggest changing all instances of "supported" to "enabled" in this requirement. -> That's why the requirement is, using other words: If 464XLAT is implemented in this CE, enable it (by means of enabling the CLAT). I'm talking here only in the CE, because the S46 doesn't include support for 464XLAT, so we can't use it to check it ... I haven't gone through the entire document yet, but you may want to look for other cases where you use "supported" where you really should use "enabled". TRANS-1 is fine because it really is just talking about ensuring the code exists (is implemented) on the device. You may also want to consider requirements for conditions under which some of the supported features are automatically enabled. For example, for 464XLAT, should PCP (if implemented) be automatically enabled when 464XLAT is enabled? Or when CLAT is enabled? -> Will do, anyway, I can wait a few extra days if you will have time to do an in-depth review of the document? We may also want to consider whether to recommend that a Transition CE Router by default has all these mechanisms enabled. There should probably also be a requirement that indicates it should be possible to enable/disable any of these mechanisms. At this stage if the game, we need to be sure we can defend against brokenness. -> I think in the case of all the other transition, this can be done by means of S46, but will review again this point, just in case something else need to be suggested/amended. Of course, in general I expect the CEs to implement in the CLI or GUI, or other management interfaces (as they do today) a way to explicitly disable/enable a mechanism. Do you think we should have that as an explicit requirement? Barbara ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Wed Jun 6 08:43: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 6942C130F4D for ; Wed, 6 Jun 2018 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Mb1dgI3YlK36 for ; Wed, 6 Jun 2018 08:43:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76719130F5B for ; Wed, 6 Jun 2018 08:43:52 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w56Fa7td014842; Wed, 6 Jun 2018 11:43:47 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2jegxau04g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 11:43:47 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56Fhj0v012338; Wed, 6 Jun 2018 11:43:45 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56FheDT012242; Wed, 6 Jun 2018 11:43:40 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 4FCE04014042; Wed, 6 Jun 2018 15:43:40 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30487.vci.att.com (Service) with ESMTPS id 3A1874014041; Wed, 6 Jun 2018 15:43:40 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0399.000; Wed, 6 Jun 2018 11:43:39 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "v6ops@ietf.org list" Thread-Topic: transition-ipv4aas-01: 464XLAT and NAT Thread-Index: AdP9pEC/p94JUP/GRw+FQnK43DDYEwAIs8aAAAfbkaA= Date: Wed, 6 Jun 2018 15:43:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD548C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDD528A@GAALPA1MSGUSRBF.ITServices.sbc.com> <5A741202-FAB8-4785-A624-28D62650FB1C@consulintel.es> In-Reply-To: <5A741202-FAB8-4785-A624-28D62650FB1C@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060177 Archived-At: Subject: Re: [v6ops] transition-ipv4aas-01: 464XLAT and NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 15:43:57 -0000 PiBGcm9tOiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+ DQo+IEhpIEJhcmJhcmEsDQo+IA0KPiBJdCBpcyBmb2xsb3dpbmcgc2VjdGlvbiA2LjMgb2YgUkZD Njg3NyAoNDY0WExBVCkuDQo+IA0KPiBJdCBpcyB0cnVlIHRoYXQgUkZDODI3MyBpcyBtdWNoIG1v cmUgcmVjZW50LCBhbmQgb2J2aW91c2x5IGl0IHdhcyBub3QNCj4gY29uc2lkZXJlZCwgYnV0IGlu IGEgcXVpY2sgY29uc2lkZXJhdGlvbiBJIHRoaW5rIGl0IGlzIGEgdmVyeSBjb21wbGV4IHNjZW5h cmlvLCBpZg0KPiB5b3UncmUgdXNpbmcgREhDUHY2LVBEIHRvIGFsc28gdXNlIFJGQzgyNzMgLi4u DQo+IA0KPiBJdCBtYXkgYmUgcG9zc2libGUsIGJ1dCBJJ20gbm90IGNvbXBsZXRlbHkgc3VyZSBp ZiB5b3UgYXJlIHRoaW5raW5nIGluIHNvbWUNCj4gc3BlY2lmaWMgc2NlbmFyaW8gdGhhdCBJIGRv bid0IHNlZSByaWdodCBub3c/DQoNClNlY3Rpb24gNi4zIG9mIFJGQyA2ODc3IGlzIGNsZWFybHkg cmVxdWlyaW5nIG11bHRpcGxlIC82NCBwcmVmaXhlcywgd2hpY2ggUkZDIDgyNzMgY2Fubm90IGRl bGl2ZXIuIEJ1dCBTZWN0aW9uIDYuMyBpcyBhbHNvIG1ha2luZyBpdCBjbGVhciB0aGF0IGl0IGlz IHJlYWxseSBhYm91dCAqaGF2aW5nKiB0aGUgbXVsdGlwbGUgLzY0IHByZWZpeGVzIChpbmNsdWRp bmcgYSBkZWRpY2F0ZWQgLzY0IGZvciB0aGUgdHJhbnNsYXRpb24pLCBhbmQgbm90IGhvdyB0aGUg cHJlZml4ZXMgYXJlIGFjcXVpcmVkICh0aG91Z2ggaXQgZG9lcywgdW5mb3J0dW5hdGVseSwgaW5j bHVkZSB0aGUgcGhyYXNlICJXaGVuIGEgZGVkaWNhdGVkIC82NCBwcmVmaXggaXMgbm90IGF2YWls YWJsZSBmb3IgdHJhbnNsYXRpb24gZnJvbSBESENQdjYtUEQiLCBpdCBzZWVtcyB0byBtZSBmcm9t IHRoZSBwcmV2aW91cyBzZW50ZW5jZXMgdGhhdCB0aGUgaW50ZW50IGlzIGZvciB0aGVyZSB0byBi ZSBhIGRlZGljYXRlZCAvNjQgYW5kIHRoZSBhdXRob3JzIHdlcmVuJ3QgdGhpbmtpbmcgYWJvdXQg dGhlIHBvc3NpYmlsaXR5IG9mIG90aGVyIG1lYW5zIGZvciBwcmVmaXggYWNxdWlzaXRpb24uIEl0 IHNob3VsZG4ndCBtYXR0ZXIgaG93IHRoZSBwcmVmaXhlcyBhcmUgYWNxdWlyZWQuIFRoZSBjdXJy ZW50IDQ2NFhMQVQtMSBzdWdnZXN0cyB0aGF0IGl0IGRvZXMgbWF0dGVyIGhvdyB0aGUgcHJlZml4 IGlzIGFjcXVpcmVkLiBUaGUgNDY0WExBVC0xIGxhbmd1YWdlIHNheXMgaWYgYSBkZWRpY2F0ZWQg cHJlZml4IHdlcmUgYWNxdWlyZWQgYnkgbWFudWFsIHByb3Zpc2lvbmluZyBvciBzb21lIG90aGVy IGZ1dHVyZSBtZWNoYW5pc20sIHRoYXQgd291bGQgbm90IGJlIHN1ZmZpY2llbnQgdG8gYXZvaWQg TkFUNDQuIE9ubHkgYSAvNjQgYWNxdWlyZWQgYnkgSUFfUEQgY2FuIGF2b2lkIE5BVDQ0LiANCg0K VGhhdCBzZWVtcyBiaXphcnJlIHRvIG1lLCBzbyBJJ2QgcmVhbGx5IGxpa2Ugc29tZW9uZSB0byBl eHBsYWluIHRoaXMgYmV0dGVyIHRvIG1lLCB3aHkgcHJlZml4IGFjcXVpc2l0aW9uIG1ldGhvZCBt YXR0ZXJzLiBTaW1wbHkgcG9pbnRpbmcgdG8gUkZDIDY4NzcgaXMgaW5zdWZmaWNpZW50LCBiZWNh dXNlIHRoYXQgcHJvdmlkZXMgbm8ganVzdGlmaWNhdGlvbiBmb3Igd2h5IG9ubHkgYWNxdWlzaXRp b24gdmlhIElBX1BEIGlzIGFjY2VwdGFibGUuIElmIG1ldGhvZCBkb2Vzbid0IG1hdHRlciwgdGhl biAidXNpbmcgREhDUHY2LVBEIFtSRkMzNjMzXSAoSVB2NiBQcmVmaXggT3B0aW9ucyBmb3IgREhD UHY2KSIgc2hvdWxkIGJlIGRlbGV0ZWQgZnJvbSB0aGUgZW5kIG9mIHRoZSByZXF1aXJlbWVudC4g DQpCYXJiYXJhDQogDQo+IFJlZ2FyZHMsDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IO+7vy0tLS0t TWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IERlOiAiU1RBUkssIEJBUkJBUkEgSCIgPGJzNzY1MkBh dHQuY29tPg0KPiBGZWNoYTogbWnDqXJjb2xlcywgNiBkZSBqdW5pbyBkZSAyMDE4LCAxNjo0NA0K PiBQYXJhOiAnSk9SREkgUEFMRVQgTUFSVElORVonIDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5l cz4sICJ2Nm9wc0BpZXRmLm9yZw0KPiBsaXN0IiA8djZvcHNAaWV0Zi5vcmc+DQo+IEFzdW50bzog dHJhbnNpdGlvbi1pcHY0YWFzLTAxOiA0NjRYTEFUIGFuZCBOQVQNCj4gDQo+ICAgICBJIHNlZToN Cj4gICAgICAgICAgNDY0WExBVC0xOiAgVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVT VCBwZXJmb3JtIElQdjQgTmV0d29yaw0KPiAgICAgICAgICAgICAgICAgICAgQWRkcmVzcyBUcmFu c2xhdGlvbiAoTkFUKSBvbiBJUHY0IHRyYWZmaWMgdHJhbnNsYXRlZA0KPiAgICAgICAgICAgICAg ICAgICAgdXNpbmcgdGhlIENMQVQsIHVubGVzcyBhIGRlZGljYXRlZCAvNjQgcHJlZml4IGhhcyBi ZWVuDQo+ICAgICAgICAgICAgICAgICAgICBhY3F1aXJlZCB1c2luZyBESENQdjYtUEQgW1JGQzM2 MzNdIChJUHY2IFByZWZpeCBPcHRpb25zDQo+ICAgICAgICAgICAgICAgICAgICBmb3IgREhDUHY2 KS4NCj4gICAgIGFuZCBhbSBjdXJpb3VzIHdoeSB0aGUgZGVkaWNhdGVkIC82NCBwcmVmaXggZXhj bHVzaW9uIGFwcGxpZXMgb25seSB0byBhDQo+IHByZWZpeCBhY3F1aXJlZCBieSBJQV9QRCwgYW5k IG5vdCBvbmUgYWNxdWlyZWQgYnkgUkZDIDgyNzM/DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0K PiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cuY29uc3VsaW50ZWwu ZXMmZD1Ed0lGYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNj OFNZOFRxNHZyZm9nJm09V3BtRjVhTTY3Q2tzajYxVG5Zd0kxR3JzVGx3Q1ExNHRtMWxhZm5UVTg4 QSYNCj4gcz1GYWtCRmpKMktqYmdldWE4ZVlERTZNYUduQVNoaG9PbjRER1dnWGg3bUFjJmU9DQo+ IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNvbmZpZGVudGlhbC4g VGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiB0aGUNCj4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGlj aWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsDQo+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYNCj4gcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IHdpbGwgYmUgY29uc2lkZXJlZCBhDQo+IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkNCj4gZGlzY2xvc3VyZSwg Y29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiwNCj4gZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwg b2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0bw0KPiBp bmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+IA0KPiANCg0K From nobody Wed Jun 6 09:02: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 F39FF130F6C for ; Wed, 6 Jun 2018 09:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dLqm0tbMgN2I for ; Wed, 6 Jun 2018 09:01:56 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F818130F5B for ; Wed, 6 Jun 2018 09:01:56 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w56Fu2AX028378; Wed, 6 Jun 2018 12:01:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2jehvxhw2g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 12:01:51 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56G1oRC020968; Wed, 6 Jun 2018 12:01:51 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56G1iJb020576; Wed, 6 Jun 2018 12:01:44 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 2D2D740002BD; Wed, 6 Jun 2018 16:01:44 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30483.vci.att.com (Service) with ESMTPS id 1964A40002A7; Wed, 6 Jun 2018 16:01:44 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0399.000; Wed, 6 Jun 2018 12:01:43 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "v6ops@ietf.org list" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Thread-Index: AQHT9mNCLmiS3PpdIUysWpj3Js08m6RTeQ0AgAACTQCAAAXRgP//xwWAgABIgoD//8yeMIAATTCA///EQkA= Date: Wed, 6 Jun 2018 16:01:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD551E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD531A@GAALPA1MSGUSRBF.ITServices.sbc.com> <8CB5274B-4221-4692-A6B8-FEDA9ED0A43D@consulintel.es> In-Reply-To: <8CB5274B-4221-4692-A6B8-FEDA9ED0A43D@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060181 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:02:01 -0000 PiAgICAgPiAgICBUUkFOUy0yOiAgSWYgNDY0WExBVCBbUkZDNjg3N10gaXMNCj4gICAgID4gICAg ICAgICAgICAgIHN1cHBvcnRlZCwgdGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVTVCBl bmFibGUgdGhlDQo+ICAgICA+ICAgICAgICAgICAgICBDTEFUIChpbiBvcmRlciB0byBhdXRvbWF0 aWNhbGx5IGNvbmZpZ3VyZSA0NjRYTEFUDQo+ICAgICA+ICAgICAgICAgICAgICBbUkZDNjg3N10p LiAgSWYgNDY0WExBVCBbUkZDNjg3N10gaXMgbm90IHN1cHBvcnRlZCwgYW5kDQo+ICAgICA+ICAg ICAgICAgICAgICBtb3JlIHRoYW4gb25lIFM0NiBtZWNoYW5pc20gaXMgc3VwcG9ydGVkLCBmb2xs b3dpbmcNCj4gICAgID4gICAgICAgICAgICAgIFNlY3Rpb24gMS40IG9mIFtSRkM4MDI2XSwgTVVT VCBjaGVjayBmb3IgYSB2YWxpZCBtYXRjaCBpbg0KPiAgICAgPiAgICAgICAgICAgICAgT1BUSU9O X1M0Nl9QUklPUklUWSwgd2hpY2ggd2lsbCBhbGxvdyBjb25maWd1cmluZyBhbnkgb2YNCj4gICAg ID4gICAgICAgICAgICAgIHRoZSBvdGhlciB0cmFuc2l0aW9uIG1lY2hhbmlzbXMuDQo+IA0KPiAg ICAgSSB0aGluayB0aGUgY29taW5nbGluZyBvZiAic3VwcG9ydGVkIiBhbmQgImVuYWJsZWQiIGlz IHByb2JsZW1hdGljIGluIHRoaXMNCj4gcmVxdWlyZW1lbnQuDQo+ICAgICAiU3VwcG9ydGVkIiBt ZWFucyAodG8gbW9zdCBwZW9wbGUpIHRoZSBzYW1lIGFzICJpbXBsZW1lbnRlZCIuIFRoYXQgaXMs DQo+IHRoZSBjb2RlIGV4aXN0cy4gIkVuYWJsZWQiIG1lYW5zIHRoZSBzdXBwb3J0ZWQgY29kZSBp cyBhY3R1YWxseSBydW5uaW5nLiBKdXN0DQo+IGJlY2F1c2UgNDY0WExBVCBpcyBzdXBwb3J0ZWQg ZG9lcyBub3QgbWVhbiBpdCBpcyBlbmFibGVkLiBJZiA0NjRYTEFUIGlzIG5vdA0KPiBlbmFibGVk LCB0aGVuIGl0IG1heSBub3QgYmUgYSBnb29kIGlkZWEgdG8gYXV0b21hdGljYWxseSBlbmFibGUg Q0xBVC4gQW5kLA0KPiBsaWtld2lzZSwgdGhlIG90aGVyIG1lY2hhbmlzbXMgc2hvdWxkIG9ubHkg YmUgY29uZmlndXJlZCBpZiB0aGV5IGFyZQ0KPiBlbmFibGVkIGFuZCBub3QgbWVyZWx5IHN1cHBv cnRlZC4gSSBzdWdnZXN0IGNoYW5naW5nIGFsbCBpbnN0YW5jZXMgb2YNCj4gInN1cHBvcnRlZCIg dG8gImVuYWJsZWQiIGluIHRoaXMgcmVxdWlyZW1lbnQuDQo+IA0KPiAtPiBUaGF0J3Mgd2h5IHRo ZSByZXF1aXJlbWVudCBpcywgdXNpbmcgb3RoZXIgd29yZHM6IElmIDQ2NFhMQVQgaXMNCj4gaW1w bGVtZW50ZWQgaW4gdGhpcyBDRSwgZW5hYmxlIGl0IChieSBtZWFucyBvZiBlbmFibGluZyB0aGUg Q0xBVCkuIEknbSB0YWxraW5nDQo+IGhlcmUgb25seSBpbiB0aGUgQ0UsIGJlY2F1c2UgdGhlIFM0 NiBkb2Vzbid0IGluY2x1ZGUgc3VwcG9ydCBmb3IgNDY0WExBVCwgc28NCj4gd2UgY2FuJ3QgdXNl IGl0IHRvIGNoZWNrIGl0IC4uLg0KDQpBcmUgeW91IHNheWluZzoNCigxKSBJZiA0NjRYTEFUIGlz IGltcGxlbWVudGVkLCB0aGUgZGVmYXVsdCBjb25maWd1cmF0aW9uIE1VU1QgaGF2ZSBDTEFUIGVu YWJsZWQuDQooMikgSWYgNDY0WExBVCBpcyBpbXBsZW1lbnRlZCwgdGhlbiBDTEFUIE1VU1QgYWx3 YXlzIGJlIGVuYWJsZWQgYW5kIHRoZXJlIE1VU1QgYmUgbm8gd2F5IHRvIGRpc2FibGUgaXQuDQpX aGlsZSBJIHRoaW5rICgxKSBtYXkgYmUgb2ssIEkgdGhpbmsgKDIpIGlzIGFuIGluY3JlZGlibHkg YmFkIGlkZWEuIEFzIHlvdSBkZXNjcmliZSBpdCwgdGhlIHJlcXVpcmVtZW50IHJlYWRzIG1vcmUg bGlrZSAoMikgdGhhbiAoMSkuDQogIA0KPiAgICAgSSBoYXZlbid0IGdvbmUgdGhyb3VnaCB0aGUg ZW50aXJlIGRvY3VtZW50IHlldCwgYnV0IHlvdSBtYXkgd2FudCB0byBsb29rDQo+IGZvciBvdGhl ciBjYXNlcyB3aGVyZSB5b3UgdXNlICJzdXBwb3J0ZWQiIHdoZXJlIHlvdSByZWFsbHkgc2hvdWxk IHVzZQ0KPiAiZW5hYmxlZCIuIFRSQU5TLTEgaXMgZmluZSBiZWNhdXNlIGl0IHJlYWxseSBpcyBq dXN0IHRhbGtpbmcgYWJvdXQgZW5zdXJpbmcgdGhlDQo+IGNvZGUgZXhpc3RzIChpcyBpbXBsZW1l bnRlZCkgb24gdGhlIGRldmljZS4gWW91IG1heSBhbHNvIHdhbnQgdG8gY29uc2lkZXINCj4gcmVx dWlyZW1lbnRzIGZvciBjb25kaXRpb25zIHVuZGVyIHdoaWNoIHNvbWUgb2YgdGhlIHN1cHBvcnRl ZCBmZWF0dXJlcw0KPiBhcmUgYXV0b21hdGljYWxseSBlbmFibGVkLiBGb3IgZXhhbXBsZSwgZm9y IDQ2NFhMQVQsIHNob3VsZCBQQ1AgKGlmDQo+IGltcGxlbWVudGVkKSBiZSBhdXRvbWF0aWNhbGx5 IGVuYWJsZWQgd2hlbiA0NjRYTEFUIGlzIGVuYWJsZWQ/IE9yIHdoZW4NCj4gQ0xBVCBpcyBlbmFi bGVkPw0KPiANCj4gLT4gV2lsbCBkbywgYW55d2F5LCBJIGNhbiB3YWl0IGEgZmV3IGV4dHJhIGRh eXMgaWYgeW91IHdpbGwgaGF2ZSB0aW1lIHRvIGRvIGFuDQo+IGluLWRlcHRoIHJldmlldyBvZiB0 aGUgZG9jdW1lbnQ/DQoNCkkgbWF5IG5vdCBoYXZlIHRpbWUuIEkgaGF2ZSB0byBmb2N1cyBvbiBv dGhlciBwcmlvcml0aWVzIGZvciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MuDQogDQo+ICAgICBX ZSBtYXkgYWxzbyB3YW50IHRvIGNvbnNpZGVyIHdoZXRoZXIgdG8gcmVjb21tZW5kIHRoYXQgYSBU cmFuc2l0aW9uIENFDQo+IFJvdXRlciBieSBkZWZhdWx0IGhhcyBhbGwgdGhlc2UgbWVjaGFuaXNt cyBlbmFibGVkLiBUaGVyZSBzaG91bGQgcHJvYmFibHkNCj4gYWxzbyBiZSBhIHJlcXVpcmVtZW50 IHRoYXQgaW5kaWNhdGVzIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBlbmFibGUvZGlzYWJsZQ0K PiBhbnkgb2YgdGhlc2UgbWVjaGFuaXNtcy4gQXQgdGhpcyBzdGFnZSBpZiB0aGUgZ2FtZSwgd2Ug bmVlZCB0byBiZSBzdXJlIHdlDQo+IGNhbiBkZWZlbmQgYWdhaW5zdCBicm9rZW5uZXNzLg0KPiAN Cj4gLT4gSSB0aGluayBpbiB0aGUgY2FzZSBvZiBhbGwgdGhlIG90aGVyIHRyYW5zaXRpb24sIHRo aXMgY2FuIGJlIGRvbmUgYnkgbWVhbnMgb2YNCj4gUzQ2LCBidXQgd2lsbCByZXZpZXcgYWdhaW4g dGhpcyBwb2ludCwganVzdCBpbiBjYXNlIHNvbWV0aGluZyBlbHNlIG5lZWQgdG8gYmUNCj4gc3Vn Z2VzdGVkL2FtZW5kZWQuIE9mIGNvdXJzZSwgaW4gZ2VuZXJhbCBJIGV4cGVjdCB0aGUgQ0VzIHRv IGltcGxlbWVudCBpbg0KPiB0aGUgQ0xJIG9yIEdVSSwgb3Igb3RoZXIgbWFuYWdlbWVudCBpbnRl cmZhY2VzIChhcyB0aGV5IGRvIHRvZGF5KSBhIHdheSB0bw0KPiBleHBsaWNpdGx5IGRpc2FibGUv ZW5hYmxlIGEgbWVjaGFuaXNtLiBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgdGhhdCBhcw0K PiBhbiBleHBsaWNpdCByZXF1aXJlbWVudD8NCg0KWWVzLCBpdCBzaG91bGQgYmUgYW4gZXhwbGlj aXQgcmVxdWlyZW1lbnQuIElmIHRoZSBpbnRlbnQgb2YgYW4gImVuYWJsZWQiIHN0YXRlbWVudCBp cyB0byBoYXZlIGl0IGVuYWJsZWQgYXMgZGVmYXVsdCBjb25maWd1cmF0aW9uLCB0aGVuIHRoZSBw aHJhc2UgImRlZmF1bHQgY29uZmlndXJhdGlvbiIgbmVlZHMgdG8gYmUgdXNlZC4gSW4gY2FzZXMg d2hlcmUgdGhlcmUgaXMgYSB0cmlnZ2VyIHRoYXQgY2F1c2VzIGEgZnVuY3Rpb24gdG8gYmVjb21l IGVuYWJsZWQsIGl0IG5lZWRzIHRvIGJlIGNsZWFyIHdoYXQgdGhlIHRyaWdnZXIgaXMuIE1lcmUg cHJlc2VuY2Ugb2YgY29kZSAoaW1wbGVtZW50YXRpb24pIHNob3VsZCBuZXZlciBiZSBzdWNoIGEg dHJpZ2dlci4gQnV0IHByZXNlbmNlIG9mIGNvZGUgaXMgcmVhc29uYWJsZSBhcyBzb21ldGhpbmcg dGhhdCBjYW4gaW1wYWN0IGRlZmF1bHQgY29uZmlndXJhdGlvbi4NCiANCkJhcmJhcmENCg== From nobody Wed Jun 6 09:08: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 477FD130F6D for ; Wed, 6 Jun 2018 09:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EczA8G_s_T5Y for ; Wed, 6 Jun 2018 09:07:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC7C130F6C for ; Wed, 6 Jun 2018 09:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528301274; x=1528906074; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=CXZACLfW IRNoIvW8ELqdPbBfhMsYTiBx+ShkYxEm/F0=; b=Z7vC3ddXtMhDVBBks1Kmgz6i Gx58jBd6zVrOELYDjgPc5whx+HBSgJaXXWXXCY5JSCbm9taJcTyXfKSNAH3EXbN/ sb3h0r6MZszZRhKx8pWbQRc1EJf48Ct4r29mNHP8rSFW9BRiG5X/3eTl2093i1bW bY0L/XwvAg0xP9yFJBA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 18:07:54 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 18:07:53 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783318.msg for ; Wed, 06 Jun 2018 18:07:53 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 18:07:53 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 18:07:50 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , "v6ops@ietf.org list" Message-ID: <3F26BC3B-6537-4321-92B5-DE04603A7F68@consulintel.es> Thread-Topic: transition-ipv4aas-01: 464XLAT and NAT References: <2D09D61DDFA73D4C884805CC7865E6114DDD528A@GAALPA1MSGUSRBF.ITServices.sbc.com> <5A741202-FAB8-4785-A624-28D62650FB1C@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD548C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD548C@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] transition-ipv4aas-01: 464XLAT and NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:08:06 -0000 I guess the point is that whatever is the mechanism you use to provision th= e /64 prefixes, the CE need to make sure to use it only for the CLAT, but a= nyway that's out of our scope ... it is something for the RFC6877. I see two choices: 1) Make it an example 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Netwo= rk Address Translation (NAT) on IPv4 traffic translated using the CLAT, unless a dedicated /64 prefix has been acquired, for example as indicated in Section 6.3 of RF= C6877, using DHCPv6-PD [RFC3633] (IPv6 Prefix Options for DHCP= v6). 2) Remove it 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 Netwo= rk Address Translation (NAT) on IPv4 traffic translated using the CLAT, unless a dedicated /64 prefix has been acquired. I think the example in choice 1, make sense to match the RFC6877 text, but = I'm fine either way. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 17:43 Para: 'JORDI PALET MARTINEZ' , "v6ops@ietf.org = list" Asunto: RE: transition-ipv4aas-01: 464XLAT and NAT > From: JORDI PALET MARTINEZ > Hi Barbara, >=20 > It is following section 6.3 of RFC6877 (464XLAT). >=20 > It is true that RFC8273 is much more recent, and obviously it was not > considered, but in a quick consideration I think it is a very complex= scenario, if > you're using DHCPv6-PD to also use RFC8273 ... >=20 > It may be possible, but I'm not completely sure if you are thinking i= n some > specific scenario that I don't see right now? =20 Section 6.3 of RFC 6877 is clearly requiring multiple /64 prefixes, whi= ch RFC 8273 cannot deliver. But Section 6.3 is also making it clear that it= is really about *having* the multiple /64 prefixes (including a dedicated = /64 for the translation), and not how the prefixes are acquired (though it = does, unfortunately, include the phrase "When a dedicated /64 prefix is not= available for translation from DHCPv6-PD", it seems to me from the previou= s sentences that the intent is for there to be a dedicated /64 and the auth= ors weren't thinking about the possibility of other means for prefix acquis= ition. It shouldn't matter how the prefixes are acquired. The current 464XL= AT-1 suggests that it does matter how the prefix is acquired. The 464XLAT-1= language says if a dedicated prefix were acquired by manual provisioning o= r some other future mechanism, that would not be sufficient to avoid NAT44.= Only a /64 acquired by IA_PD can avoid NAT44.=20 =20 That seems bizarre to me, so I'd really like someone to explain this be= tter to me, why prefix acquisition method matters. Simply pointing to RFC 6= 877 is insufficient, because that provides no justification for why only ac= quisition via IA_PD is acceptable. If method doesn't matter, then "using DH= CPv6-PD [RFC3633] (IPv6 Prefix Options for DHCPv6)" should be deleted from = the end of the requirement.=20 Barbara =20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: "STARK, BARBARA H" > Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 16:44 > Para: 'JORDI PALET MARTINEZ' , "v6ops@iet= f.org > list" > Asunto: transition-ipv4aas-01: 464XLAT and NAT >=20 > I see: > 464XLAT-1: The IPv6 Transition CE Router MUST perform IPv4 = Network > Address Translation (NAT) on IPv4 traffic translat= ed > using the CLAT, unless a dedicated /64 prefix has = been > acquired using DHCPv6-PD [RFC3633] (IPv6 Prefix Op= tions > for DHCPv6). > and am curious why the dedicated /64 prefix exclusion applies onl= y to a > prefix acquired by IA_PD, and not one acquired by RFC 8273? >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__www.consulintel.es&d=3DDwIFaQ&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DWpmF5aM67Cksj61TnYwI1GrsTlwCQ14tm1lafnTU88A& > s=3DFakBFjJ2Kjbgeua8eYDE6MaGnAShhoOn4DGWgXh7mAc&e=3D > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be considered a > criminal offense. If you are not the intended recipient be aware that= any > disclosure, copying, distribution or use of the contents of this info= rmation, > even if partially, including attached files, is strictly prohibited, = will be > considered a criminal offense, so you must reply to the original send= er to > inform about this communication and delete it. >=20 >=20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 09:15: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 C7431130F81 for ; Wed, 6 Jun 2018 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 958zx44tnQUb for ; Wed, 6 Jun 2018 09:15:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E59130F78 for ; Wed, 6 Jun 2018 09:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528301729; x=1528906529; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Df4Ew7YO lFakzdwaqoes7I7O943/R3Jtm6VLcOwcKrk=; b=fzOO8pAyQdm97Z+5vNfKHQlJ pGhGeIXZBzgllDxCvbxRxQxG+LQBuxyer36rkbppdemLNriil8/AwWu7jlIJdN9M 2XRSDKmi0zCD+tgLuQCftKP4qoczXynOZS7xgqlTKqn1hKVLGbUDamtpx3Z5H4Qg mQKjpiy2FqJdhE/d5U4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 18:15:29 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 18:15:28 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783323.msg for ; Wed, 06 Jun 2018 18:15:28 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 18:15:28 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 18:15:23 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , "v6ops@ietf.org list" Message-ID: <6C5D1CC4-CEF2-439B-9771-DCA9577AA980@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD531A@GAALPA1MSGUSRBF.ITServices.sbc.com> <8CB5274B-4221-4692-A6B8-FEDA9ED0A43D@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD551E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD551E@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:15:38 -0000 > > TRANS-2: If 464XLAT [RFC6877] is > > supported, the IPv6 Transition CE Router MUST enable the > > CLAT (in order to automatically configure 464XLAT > > [RFC6877]). If 464XLAT [RFC6877] is not supported, and > > more than one S46 mechanism is supported, following > > Section 1.4 of [RFC8026], MUST check for a valid match in > > OPTION_S46_PRIORITY, which will allow configuring any of > > the other transition mechanisms. > > I think the comingling of "supported" and "enabled" is problematic in this > requirement. > "Supported" means (to most people) the same as "implemented". That is, > the code exists. "Enabled" means the supported code is actually running. Just > because 464XLAT is supported does not mean it is enabled. If 464XLAT is not > enabled, then it may not be a good idea to automatically enable CLAT. And, > likewise, the other mechanisms should only be configured if they are > enabled and not merely supported. I suggest changing all instances of > "supported" to "enabled" in this requirement. > > -> That's why the requirement is, using other words: If 464XLAT is > implemented in this CE, enable it (by means of enabling the CLAT). I'm talking > here only in the CE, because the S46 doesn't include support for 464XLAT, so > we can't use it to check it ... Are you saying: (1) If 464XLAT is implemented, the default configuration MUST have CLAT enabled. (2) If 464XLAT is implemented, then CLAT MUST always be enabled and there MUST be no way to disable it. While I think (1) may be ok, I think (2) is an incredibly bad idea. As you describe it, the requirement reads more like (2) than (1). -> Right now, is 2. Because we don't have an explicit way to check if 464XLAT is being used by the ISP by means of S46 (one possibility will be to update S46 to support 464XLAT), but we can make it this way: TRANS-2: If 464XLAT [RFC6877] is supported, the IPv6 Transition CE Router MUST enable the CLAT (in order to automatically configure 464XLAT [RFC6877]), unless an alternative S46 mechanism is supported, and following Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which will allow configuring any of the other transition mechanisms. > I haven't gone through the entire document yet, but you may want to look > for other cases where you use "supported" where you really should use > "enabled". TRANS-1 is fine because it really is just talking about ensuring the > code exists (is implemented) on the device. You may also want to consider > requirements for conditions under which some of the supported features > are automatically enabled. For example, for 464XLAT, should PCP (if > implemented) be automatically enabled when 464XLAT is enabled? Or when > CLAT is enabled? > > -> Will do, anyway, I can wait a few extra days if you will have time to do an > in-depth review of the document? I may not have time. I have to focus on other priorities for the next couple of weeks. > We may also want to consider whether to recommend that a Transition CE > Router by default has all these mechanisms enabled. There should probably > also be a requirement that indicates it should be possible to enable/disable > any of these mechanisms. At this stage if the game, we need to be sure we > can defend against brokenness. > > -> I think in the case of all the other transition, this can be done by means of > S46, but will review again this point, just in case something else need to be > suggested/amended. Of course, in general I expect the CEs to implement in > the CLI or GUI, or other management interfaces (as they do today) a way to > explicitly disable/enable a mechanism. Do you think we should have that as > an explicit requirement? Clear, then will draft a requirement for this: Yes, it should be an explicit requirement. If the intent of an "enabled" statement is to have it enabled as default configuration, then the phrase "default configuration" needs to be used. In cases where there is a trigger that causes a function to become enabled, it needs to be clear what the trigger is. Mere presence of code (implementation) should never be such a trigger. But presence of code is reasonable as something that can impact default configuration. Barbara ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Wed Jun 6 09:44: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 E5BE2130F7E for ; Wed, 6 Jun 2018 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 x69WCruFxCpC for ; Wed, 6 Jun 2018 09:44:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C3C130F72 for ; Wed, 6 Jun 2018 09:44:07 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w56EZe6T034710; Wed, 6 Jun 2018 10:44:15 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2jefh1vsfc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 10:44:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56EiDZR022014; Wed, 6 Jun 2018 10:44:13 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56Ei631021864; Wed, 6 Jun 2018 10:44:06 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 3A95840002B6; Wed, 6 Jun 2018 14:44:06 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30488.vci.att.com (Service) with ESMTPS id 18B3B40002AE; Wed, 6 Jun 2018 14:44:06 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0399.000; Wed, 6 Jun 2018 10:44:05 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "v6ops@ietf.org list" Thread-Topic: transition-ipv4aas-01: 464XLAT and NAT Thread-Index: AdP9pEC/p94JUP/GRw+FQnK43DDYEw== Date: Wed, 6 Jun 2018 14:44:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD528A@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=634 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060168 Archived-At: Subject: [v6ops] transition-ipv4aas-01: 464XLAT and NAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:44:11 -0000 SSBzZWU6DQogICAgIDQ2NFhMQVQtMTogIFRoZSBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIE1V U1QgcGVyZm9ybSBJUHY0IE5ldHdvcmsNCiAgICAgICAgICAgICAgIEFkZHJlc3MgVHJhbnNsYXRp b24gKE5BVCkgb24gSVB2NCB0cmFmZmljIHRyYW5zbGF0ZWQNCiAgICAgICAgICAgICAgIHVzaW5n IHRoZSBDTEFULCB1bmxlc3MgYSBkZWRpY2F0ZWQgLzY0IHByZWZpeCBoYXMgYmVlbg0KICAgICAg ICAgICAgICAgYWNxdWlyZWQgdXNpbmcgREhDUHY2LVBEIFtSRkMzNjMzXSAoSVB2NiBQcmVmaXgg T3B0aW9ucw0KICAgICAgICAgICAgICAgZm9yIERIQ1B2NikuDQphbmQgYW0gY3VyaW91cyB3aHkg dGhlIGRlZGljYXRlZCAvNjQgcHJlZml4IGV4Y2x1c2lvbiBhcHBsaWVzIG9ubHkgdG8gYSBwcmVm aXggYWNxdWlyZWQgYnkgSUFfUEQsIGFuZCBub3Qgb25lIGFjcXVpcmVkIGJ5IFJGQyA4MjczPyAN Cg== From nobody Wed Jun 6 10:01: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 BFA3D130F81 for ; Wed, 6 Jun 2018 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TphzjwATv4dn for ; Wed, 6 Jun 2018 10:01:36 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44744130F66 for ; Wed, 6 Jun 2018 10:01:36 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id h12-v6so3440607pfk.11 for ; Wed, 06 Jun 2018 10:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RIH9WLeqnpYNGohcO60B3oowvVsQtPJMgSJtPxRbkvk=; b=hTjNFyImfUU7+HdYssdBhuXUXRrJheN4d3JBuF/uH83yM4ckAwfyukjIWRaFforQaf y4YLBzUVPpvkYp1yEnAIFEBc91S74ARtF6Ydd7y5DgTOmKj4f0XsGrwdwj/6Mwm66pMk 54J7H3wh64AqG99rR9FSoukI6ChlICN2ZuZWVn4lPBUq+TXKk4NSGv6on1tYBi2ono2N k20SlxcBPmUjCPatS+7QjCGHfpgSC9DQ+n/I7Rh9rscEIgQ6tewIwkerLutApYVB5aT8 VYe9Qa0MUvMk/r3MjyXqUloauDOWMghbkBrr0BLhuyxkFhIwv9GpspSO6r2HJB3Bsxi8 A2hQ== 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=RIH9WLeqnpYNGohcO60B3oowvVsQtPJMgSJtPxRbkvk=; b=s2+FyR66FHR+j55nFZGlAYYwX4raKvKHXJ1POaQelKeuTDe+DmpARehF0TPN30/vTg y8TCPqWVwwAAO+bFUCHP34NhfwYHvDAEKOoFePrrLMOVrqd3etLv9dGWDS61yrEzzDLC 9mKH6lHkeIvsMnAGKRT/K/HPYRsJkBCzYldM/mDgfIjZ8PAORt6IE17Fpv7334o+DJvz jIgcL/1Egqgo+ezW3j3kG/NfQdVk0DegR0wHf8o8lnwsCN2OxvCdQT71K1A6u02jtASo lDFFrR18VLk4q5A49soj1533ATv0a65uU+Scu9dAbHAs64fo22s7TTs/FEwfznA2nh7i 6CVQ== X-Gm-Message-State: APt69E25dXOWo7LVD79QVKhpfPD1RVROAWasZw83xFaUmirwQJcZdtfl y5JyWDOZpc7Wb9aFEV6tjWBcj6zP X-Google-Smtp-Source: ADUXVKJk+Y/GfjWHUwmg5VDxRfp3iADCxMysA42Y+CvAhj0LTgu+gRmV/5sb36owO3gP3XSOsa0jxg== X-Received: by 2002:a65:644a:: with SMTP id s10-v6mr3218765pgv.360.1528304495051; Wed, 06 Jun 2018 10:01:35 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:1978:79a8:2a9e:fe0b? ([2601:646:c005:a10:1978:79a8:2a9e:fe0b]) by smtp.gmail.com with ESMTPSA id z3-v6sm940250pfn.36.2018.06.06.10.01.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 10:01:34 -0700 (PDT) From: Fred Baker Message-Id: <4E20241E-D7CF-42DA-9605-57F548B82614@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F738A2D7-616A-4F45-8B92-E9A27BDA9CC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 6 Jun 2018 10:01:32 -0700 In-Reply-To: Cc: "v6ops@ietf.org list" To: Richard Patterson , JORDI PALET MARTINEZ References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 17:01:41 -0000 --Apple-Mail=_F738A2D7-616A-4F45-8B92-E9A27BDA9CC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Color me wacko. I'm thinking about weird cases. No hats. Suppose I enable dual stack in a domain, and the router in question as a = result turns off transition stuff. Then IPv6 connectivity fails. Suppose the domain is IPv4-only, and native IPv6 gets turned on. Does = the transition technology stop? Let your mind spin for a while. This seems like a problem that should be solved using routing. If I = don't have a route to using native IPv6 but do using the = transition technology, I have an argument for the transition technology. = If the native route becomes available, I should think it would supersede = the transition path. Am I missing something? > On Jun 6, 2018, at 5:25 AM, Richard Patterson = wrote: >=20 > Hi Jordi, >=20 > I'm not sure that I agree with requirement TRANS-2: > "The IPv6 Transition CE Router MUST verify if the WAN link supports > native IPv4. In that case, transition mechanisms SHOULD NOT be > automatically enabled for that interface." >=20 > In fact I'd suggest the exact opposite, if a CE Router receives valid > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations > until the WAN link status changes. This could be expanded to include > a validation of a working IPv4aaS, but unsure how that should look. > For example, a brownfield IPv4aaS deployment is likely to still be > running dual stack in parallel whilst it migrates its clients to > IPv4aaS, the current wording would hinder this migration, by > preferring to stay on native (or NAT444) IPv4. >=20 > The "suspend" could also be debated, that it could be sufficient to > rely on the DHCPv4 back off mechanisms, but on a large network that > could still put a lot of extra load on the DHCPv4 server/relay and > RADIUS. My vote is to suspend temporarily until reboot/WAN change. >=20 > And anecdotally, the current behaviour of OpenWRT is to prefer the S46 > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. >=20 > -Richard > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > wrote: >>=20 >> Hi Barbara, >>=20 >> Sorry the late answer, last few weeks had been a non-stop traveling = in 3 continents and too much work ... >>=20 >> I see what you mean and we have discussed about this among the = coauthors and amended the document, including some other comments = received in the list. >>=20 >> The new version has been published a few minutes ago: >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?incl= ude_text=3D1 >>=20 >> Basically, we are keeping a MUST for retail product versions, but not = for specific ISP versions. I hope you agree with this, as we believe it = makes sense. >>=20 >> We don't update anymore the RFC7084, and we just use the same style = to add the requirements for an IPv6 Transition CE Router (and we use = this terminology across all the document). >>=20 >> The main changes are summarized in the Annex C: >> 1. ID-Nits: IANA section. >> 2. ID-Nits: RFC7084 reference removed from Abstract. >> 3. This document no longer updates RFC7084. >> 4. UPnP section reworded. >> 5. "CE Router" changed to "IPv6 Transition CE Router". >> 6. Reduced text in Annex A. >>=20 >> Hopefully everybody agrees now with this version, and in any case, = will be very helpful if we can get any inputs. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de "STARK, BARBARA H" = >> Fecha: lunes, 30 de abril de 2018, 19:20 >> Para: V6 Ops List >> Asunto: Re: [v6ops] I-D Action: = draft-ietf-v6ops-transition-ipv4aas-00.txt >>=20 >> Hi Jordi, >> I was having a hard time understanding where you were headed with = proposed changes, by following the email thread. So I was waiting for = this update. My company's email server also refuses to deliver to me = some emails sent to this list without telling me. That probably adds to = my difficulty. >>=20 >> My suggestion related to making requirements "MUST" were tied to = also *not* making this an update to RFC 7084. >>=20 >> Here is the problem: >> If this is an update to RFC 7084, then I cannot support any "MUST" = statements. >> My employer makes use of RFC 7084. As is. Updating RFC 7084 with = additional "MUST" statements impacts my employer's ability to use and = reference RFC 7084 to get the CE routers it wants. An RFC 7084 update = with "MUST" statements (that are not needed by many current deployments) = would be harmful to the existing IPv6 ecosystem. >>=20 >> For a device profile to be usable by the vendor and ISP community, = it must contain "MUST" statements for all items that need to be required = to achieve the profile's goal. Trying to get vendors to implement lots = of "SHOULD" statements is futile. As an individual contributor, I do not = support IETF publishing a futile device profile document with many = "SHOULD" statements. >>=20 >> The solution I have proposed is to create a brand new device = profile. A device profile for something called an "IPv6 Transition CE = Router". This device profile is not an update to RFC 7084. It is its own = thing. It is free to make use of RFC 7084 any way it wants -- not at = all, in whole, or by referencing sections it does or doesn't want to = require as part of the "IPv6 Transition CE Router" device profile. >> Barbara >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >>=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 --Apple-Mail=_F738A2D7-616A-4F45-8B92-E9A27BDA9CC7 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+AFAlsYE20ACgkQEhdRnd2G P+AcYQ/9G0+2/Q1BJBK9r1UbJiojLSNHhq+DN5HUswM/wIDrJIl6Ov53zMuJ+w9q 798/18Wbn/4gB1zxMkw/PP8ome0Ea+3TlQOdJR56b3Nqp5sES4Ot+oyKv71r3Kjh 1CUyH6tYIBPOZNnyjW1mpVSnyyqcCJz1HHw3D0PlIG0vFx0GDvXqSoVQUE1zHBYN cxGYsPX8gBUR3OCaKZjkPc0YRwKm76gUoVp3Cpx47AIOyUm1nXim0t5I1Z/28juH mNXVa9184vKUk6r4xHcN9rbUJHVYpy10P1bU4ZTGYaLWLBc/7CY+EUphqlIoQUG+ 1ZplnVTJijZlmkbqTgIncxzFqz+DOs1rFoGYkJV1DSAE9StU/UEFHa16PlMP/+Di QUtw8vkL0e2iisWubt/2hP0exvhzzUz+KMhNXulakUi7YCTv5FykYWaCC+fPwk8D vhNDgA8BhKhwO12OBBTlw+qQ0stTGjl9BbLFfe28d/fIO37LBVczhVZsH/HzWMYR WXHcBYCypoeFonEQMQpIvufRKBQP5NMlMmAjmiu1n3lOzb6ivtE1diSDVkitCBxP DdykEKiQe/YmnTZGWPheYs8HhFru2fkfP6YqiVDnB8O90r34hFGpDytgXMKQINet +KaECK+6J3OzMxPGCZB8jE7tohqbAVwcJHRCHHYmhhdexV+3NCI= =w5Am -----END PGP SIGNATURE----- --Apple-Mail=_F738A2D7-616A-4F45-8B92-E9A27BDA9CC7-- From nobody Wed Jun 6 10:21: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 C96A9130F66 for ; Wed, 6 Jun 2018 10:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ0khKJkCP66 for ; Wed, 6 Jun 2018 10:21:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2F2127148 for ; Wed, 6 Jun 2018 10:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528305661; x=1528910461; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Msitq7YxSL1AyJQXSp0sb/U9W2exanFtkBPxky8dIF4=; b=U0FVQd0Gv3tPr bO7378pnfBTNHP6zAV+K8gDZjWa7opXoEks7jIXpLcNcrpaXmvjBb5D7oe6X7FdX dxuso7OJlMZTQzRbZo7eRjBW+Z3VL4gii5UBTtc08a8mZ1mqHRv0ELs2VOihfCjW EKp3/jY6OTycSkDXqNg/ljevqO5R9s= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 06 Jun 2018 19:21:01 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 06 Jun 2018 19:21:00 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005783349.msg for ; Wed, 06 Jun 2018 19:20:59 +0200 X-MDRemoteIP: 2001:470:1f09:495:15d5:46e5:92a2:a585 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 06 Jun 2018 19:20:59 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1695eae08a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 06 Jun 2018 19:20:54 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , Richard Patterson CC: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4E20241E-D7CF-42DA-9605-57F548B82614@gmail.com> In-Reply-To: <4E20241E-D7CF-42DA-9605-57F548B82614@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 17:21:09 -0000 Hi Fred, Below in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: mi=C3=A9rcoles, 6 de junio de 2018, 19:02 Para: Richard Patterson , JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Color me wacko. I'm thinking about weird cases. =20 No hats. =20 Suppose I enable dual stack in a domain, and the router in question as = a result turns off transition stuff. Then IPv6 connectivity fails. =20 Suppose the domain is IPv4-only, and native IPv6 gets turned on. Does t= he transition technology stop? =20 Let your mind spin for a while. =20 This seems like a problem that should be solved using routing. If I don= 't have a route to using native IPv6 but do using the transitio= n technology, I have an argument for the transition technology. If the nati= ve route becomes available, I should think it would supersede the transitio= n path. -> See the example from Barbara. You have dual-stack today. You want to sta= rt moving "some" customers to IPv4aas. So, you will have "both" routings wo= rking in that "region". That's why it looks like DHCP options are more sens= ible in this case and "considering" that the future is IPv6-only (and IPv4a= as is a temporary measure), the *preference* should be for the transition r= oute instead of the native-one (if both of them are available). =20 Am I missing something? =20 > On Jun 6, 2018, at 5:25 AM, Richard Patterson = wrote: >=20 > Hi Jordi, >=20 > I'm not sure that I agree with requirement TRANS-2: > "The IPv6 Transition CE Router MUST verify if the WAN link supports > native IPv4. In that case, transition mechanisms SHOULD NOT be > automatically enabled for that interface." >=20 > In fact I'd suggest the exact opposite, if a CE Router receives valid > S46 DHCP Options, it SHOULD suspend its DHCPv4/PPP IPCP operations > until the WAN link status changes. This could be expanded to include > a validation of a working IPv4aaS, but unsure how that should look. > For example, a brownfield IPv4aaS deployment is likely to still be > running dual stack in parallel whilst it migrates its clients to > IPv4aaS, the current wording would hinder this migration, by > preferring to stay on native (or NAT444) IPv4. >=20 > The "suspend" could also be debated, that it could be sufficient to > rely on the DHCPv4 back off mechanisms, but on a large network that > could still put a lot of extra load on the DHCPv4 server/relay and > RADIUS. My vote is to suspend temporarily until reboot/WAN change. >=20 > And anecdotally, the current behaviour of OpenWRT is to prefer the S4= 6 > IPv4aaS mechanism, even when presented a valid DHCPv4 lease. >=20 > -Richard > On Mon, 28 May 2018 at 10:11, JORDI PALET MARTINEZ > wrote: >>=20 >> Hi Barbara, >>=20 >> Sorry the late answer, last few weeks had been a non-stop traveling = in 3 continents and too much work ... >>=20 >> I see what you mean and we have discussed about this among the coaut= hors and amended the document, including some other comments received in th= e list. >>=20 >> The new version has been published a few minutes ago: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas= /?include_text=3D1 >>=20 >> Basically, we are keeping a MUST for retail product versions, but no= t for specific ISP versions. I hope you agree with this, as we believe it m= akes sense. >>=20 >> We don't update anymore the RFC7084, and we just use the same style = to add the requirements for an IPv6 Transition CE Router (and we use this t= erminology across all the document). >>=20 >> The main changes are summarized in the Annex C: >> 1. ID-Nits: IANA section. >> 2. ID-Nits: RFC7084 reference removed from Abstract. >> 3. This document no longer updates RFC7084. >> 4. UPnP section reworded. >> 5. "CE Router" changed to "IPv6 Transition CE Router". >> 6. Reduced text in Annex A. >>=20 >> Hopefully everybody agrees now with this version, and in any case, w= ill be very helpful if we can get any inputs. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de "STARK, BARBARA H" <= bs7652@att.com> >> Fecha: lunes, 30 de abril de 2018, 19:20 >> Para: V6 Ops List >> Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-= 00.txt >>=20 >> Hi Jordi, >> I was having a hard time understanding where you were headed with= proposed changes, by following the email thread. So I was waiting for this= update. My company's email server also refuses to deliver to me some email= s sent to this list without telling me. That probably adds to my difficulty= . >>=20 >> My suggestion related to making requirements "MUST" were tied to = also *not* making this an update to RFC 7084. >>=20 >> Here is the problem: >> If this is an update to RFC 7084, then I cannot support any "MUST= " statements. >> My employer makes use of RFC 7084. As is. Updating RFC 7084 with = additional "MUST" statements impacts my employer's ability to use and refer= ence RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST= " statements (that are not needed by many current deployments) would be har= mful to the existing IPv6 ecosystem. >>=20 >> For a device profile to be usable by the vendor and ISP community= , it must contain "MUST" statements for all items that need to be required = to achieve the profile's goal. Trying to get vendors to implement lots of "= SHOULD" statements is futile. As an individual contributor, I do not suppor= t IETF publishing a futile device profile document with many "SHOULD" state= ments. >>=20 >> The solution I have proposed is to create a brand new device prof= ile. A device profile for something called an "IPv6 Transition CE Router". = This device profile is not an update to RFC 7084. It is its own thing. It i= s free to make use of RFC 7084 any way it wants -- not at all, in whole, or= by referencing sections it does or doesn't want to require as part of the = "IPv6 Transition CE Router" device profile. >> Barbara >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged= or confidential. The information is intended to be for the exclusive use o= f the individual(s) named above and further non-explicilty authorized discl= osure, copying, distribution or use of the contents of this information, ev= en if partially, including attached files, is strictly prohibited and will = be considered a criminal offense. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, even if partially, including attached files, is strictly = prohibited, will be considered a criminal offense, so you must reply to the= original sender to inform about this communication and delete it. >>=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 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 6 14:46: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 36ED1130DE5 for ; Wed, 6 Jun 2018 14:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hS9ApUqZ7eZM for ; Wed, 6 Jun 2018 14:46:35 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A45B130DDC for ; Wed, 6 Jun 2018 14:46:34 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w56EuRJZ009227; Wed, 6 Jun 2018 11:03:55 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2jefyfmne4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 11:03:54 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56F3ru5000391; Wed, 6 Jun 2018 11:03:53 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w56F3nkj000333; Wed, 6 Jun 2018 11:03:49 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id AF45E40002DC; Wed, 6 Jun 2018 15:03:49 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30486.vci.att.com (Service) with ESMTPS id 9A3F740002D8; Wed, 6 Jun 2018 15:03:49 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0399.000; Wed, 6 Jun 2018 11:03:48 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "v6ops@ietf.org list" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Thread-Index: AQHT9mNCLmiS3PpdIUysWpj3Js08m6RTeQ0AgAACTQCAAAXRgP//xwWAgABIgoD//8yeMA== Date: Wed, 6 Jun 2018 15:03:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD531A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> <4C35EB79-A494-459B-8854-6FB2BAB1FF6E@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DDD5013@GAALPA1MSGUSRBF.ITServices.sbc.com> <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> In-Reply-To: <92BC2DC8-85D1-4757-8426-E07C88088DCF@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.195] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806060172 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:46:39 -0000 PiAgICBUUkFOUy0yOiAgSWYgNDY0WExBVCBbUkZDNjg3N10gaXMNCj4gICAgICAgICAgICAgIHN1 cHBvcnRlZCwgdGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVTVCBlbmFibGUgdGhlDQo+ ICAgICAgICAgICAgICBDTEFUIChpbiBvcmRlciB0byBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZSA0 NjRYTEFUDQo+ICAgICAgICAgICAgICBbUkZDNjg3N10pLiAgSWYgNDY0WExBVCBbUkZDNjg3N10g aXMgbm90IHN1cHBvcnRlZCwgYW5kDQo+ICAgICAgICAgICAgICBtb3JlIHRoYW4gb25lIFM0NiBt ZWNoYW5pc20gaXMgc3VwcG9ydGVkLCBmb2xsb3dpbmcNCj4gICAgICAgICAgICAgIFNlY3Rpb24g MS40IG9mIFtSRkM4MDI2XSwgTVVTVCBjaGVjayBmb3IgYSB2YWxpZCBtYXRjaCBpbg0KPiAgICAg ICAgICAgICAgT1BUSU9OX1M0Nl9QUklPUklUWSwgd2hpY2ggd2lsbCBhbGxvdyBjb25maWd1cmlu ZyBhbnkgb2YNCj4gICAgICAgICAgICAgIHRoZSBvdGhlciB0cmFuc2l0aW9uIG1lY2hhbmlzbXMu DQoNCkkgdGhpbmsgdGhlIGNvbWluZ2xpbmcgb2YgInN1cHBvcnRlZCIgYW5kICJlbmFibGVkIiBp cyBwcm9ibGVtYXRpYyBpbiB0aGlzIHJlcXVpcmVtZW50LiANCiJTdXBwb3J0ZWQiIG1lYW5zICh0 byBtb3N0IHBlb3BsZSkgdGhlIHNhbWUgYXMgImltcGxlbWVudGVkIi4gVGhhdCBpcywgdGhlIGNv ZGUgZXhpc3RzLiAiRW5hYmxlZCIgbWVhbnMgdGhlIHN1cHBvcnRlZCBjb2RlIGlzIGFjdHVhbGx5 IHJ1bm5pbmcuIEp1c3QgYmVjYXVzZSA0NjRYTEFUIGlzIHN1cHBvcnRlZCBkb2VzIG5vdCBtZWFu IGl0IGlzIGVuYWJsZWQuIElmIDQ2NFhMQVQgaXMgbm90IGVuYWJsZWQsIHRoZW4gaXQgbWF5IG5v dCBiZSBhIGdvb2QgaWRlYSB0byBhdXRvbWF0aWNhbGx5IGVuYWJsZSBDTEFULiBBbmQsIGxpa2V3 aXNlLCB0aGUgb3RoZXIgbWVjaGFuaXNtcyBzaG91bGQgb25seSBiZSBjb25maWd1cmVkIGlmIHRo ZXkgYXJlIGVuYWJsZWQgYW5kIG5vdCBtZXJlbHkgc3VwcG9ydGVkLiBJIHN1Z2dlc3QgY2hhbmdp bmcgYWxsIGluc3RhbmNlcyBvZiAic3VwcG9ydGVkIiB0byAiZW5hYmxlZCIgaW4gdGhpcyByZXF1 aXJlbWVudC4NCg0KSSBoYXZlbid0IGdvbmUgdGhyb3VnaCB0aGUgZW50aXJlIGRvY3VtZW50IHll dCwgYnV0IHlvdSBtYXkgd2FudCB0byBsb29rIGZvciBvdGhlciBjYXNlcyB3aGVyZSB5b3UgdXNl ICJzdXBwb3J0ZWQiIHdoZXJlIHlvdSByZWFsbHkgc2hvdWxkIHVzZSAiZW5hYmxlZCIuIFRSQU5T LTEgaXMgZmluZSBiZWNhdXNlIGl0IHJlYWxseSBpcyBqdXN0IHRhbGtpbmcgYWJvdXQgZW5zdXJp bmcgdGhlIGNvZGUgZXhpc3RzIChpcyBpbXBsZW1lbnRlZCkgb24gdGhlIGRldmljZS4gWW91IG1h eSBhbHNvIHdhbnQgdG8gY29uc2lkZXIgcmVxdWlyZW1lbnRzIGZvciBjb25kaXRpb25zIHVuZGVy IHdoaWNoIHNvbWUgb2YgdGhlIHN1cHBvcnRlZCBmZWF0dXJlcyBhcmUgYXV0b21hdGljYWxseSBl bmFibGVkLiBGb3IgZXhhbXBsZSwgZm9yIDQ2NFhMQVQsIHNob3VsZCBQQ1AgKGlmIGltcGxlbWVu dGVkKSBiZSBhdXRvbWF0aWNhbGx5IGVuYWJsZWQgd2hlbiA0NjRYTEFUIGlzIGVuYWJsZWQ/IE9y IHdoZW4gQ0xBVCBpcyBlbmFibGVkPw0KDQpXZSBtYXkgYWxzbyB3YW50IHRvIGNvbnNpZGVyIHdo ZXRoZXIgdG8gcmVjb21tZW5kIHRoYXQgYSBUcmFuc2l0aW9uIENFIFJvdXRlciBieSBkZWZhdWx0 IGhhcyBhbGwgdGhlc2UgbWVjaGFuaXNtcyBlbmFibGVkLiBUaGVyZSBzaG91bGQgcHJvYmFibHkg YWxzbyBiZSBhIHJlcXVpcmVtZW50IHRoYXQgaW5kaWNhdGVzIGl0IHNob3VsZCBiZSBwb3NzaWJs ZSB0byBlbmFibGUvZGlzYWJsZSBhbnkgb2YgdGhlc2UgbWVjaGFuaXNtcy4gQXQgdGhpcyBzdGFn ZSBpZiB0aGUgZ2FtZSwgd2UgbmVlZCB0byBiZSBzdXJlIHdlIGNhbiBkZWZlbmQgYWdhaW5zdCBi cm9rZW5uZXNzLiANCkJhcmJhcmENCg== From nobody Fri Jun 8 01:51: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 7891A130E48 for ; Fri, 8 Jun 2018 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6PrbYEdYYOpj for ; Fri, 8 Jun 2018 01:51:23 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A564130E70 for ; Fri, 8 Jun 2018 01:51:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AEFFCB1; Fri, 8 Jun 2018 10:51:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1528447880; bh=xYJ9j7xkuONKj4C3XnXNX1CNXQaPtVJWc9Rt0/DqI3Y=; h=Date:From:To:Subject:In-Reply-To:References:From; b=eSIctyZ55+a0jf7T4zzq2G4UXR8hHm55wKQFDC4q/6cCX8h7LiHeJVjOGUHSdwmSo bv7b6en+OMEhNpyCCR4wiAz369g1uM6cS2YEU1X8XtJA1C/gjVbYr00YYz8GCmoig8 hllUvJhGG3EpUu+vamPcnFf6EAyfLb/rKD7XFnIk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ACE7AB0 for ; Fri, 8 Jun 2018 10:51:20 +0200 (CEST) Date: Fri, 8 Jun 2018 10:51:20 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ietf.org list" 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: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 08:51:28 -0000 Hi, I'd like to bring attention to this draft. It's trying to solve a problem when using IPoE and when to consider WAN being down (RFC7084), if there is no physical link-down. I had an idea to use the ND state of the RA sending router, if ND to that doesn't work for a certain amount of time (perhaps we can even use the existing ND state and just monitor it), and if that indicates that connectivity has been dead sufficiently long, kick down DHCP T1 timers and try to renew, and if that is not successful, expire DHCP PD completly and do everything RFC7084 says to do. Thoughts? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jun 8 06:59: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 4627D130E9D for ; Fri, 8 Jun 2018 06:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 ddJeG7ClyYYH for ; Fri, 8 Jun 2018 06:59:38 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B37126CC7 for ; Fri, 8 Jun 2018 06:59:37 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w7-v6so13515579wrn.6 for ; Fri, 08 Jun 2018 06:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+GO26uIInpMLhUA5bZwnUIPf924HWH2nkYvDr+0ojrE=; b=acWx0wy4KRNFQwRfv46m0gqCtxlb40+DLiu76WPKRBGpNzORKUw0vDy0KTbALfbqgq iDomeiAICapn+77snzvDO6A+7SuCKvErVZVE0E+jpQ/I706mhQdTbaXUIYe0ryn3WF+k vG50wxu63TTbL+GIwpI4CFMZ0oPpslzYqVqgYuqgLBT7WRHbOsVBZqJ40MOl/3VQS2aP jxxWG8HcoFnbXTVj5/9JlyJ3P57Ht9yJowvdsHSPtaEO5P3UQHuI2fu7j1le0u1Wg8ev f28lXlCruPODXxcJQ6e+fZS/4qEsOfjYiiI00zcXg9ExtCzMbb9lz555B+L0ClA/mJe9 moMA== 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=+GO26uIInpMLhUA5bZwnUIPf924HWH2nkYvDr+0ojrE=; b=qqBO6JgfiuzrYDTBKgfXyUyRe3sw2nuzAate1LfXp6YeIODfIj362mMSYvDHr8MxGt ufdldEXwBAwEXomD+uiFwjNa29s+jzIQvQvlXjA+/U/cSHz4QkXkiE4H7jadYPbrmqk6 DZCl2p9KQezefUzf3vCK+V1fyskUrdLIwW9j//A72vD/MWvX7WhnzIHFfEdsxcQqk9zh AFEKul9xXc+dYhR/cfFbY4Te38vFgstnfRvrMaQK0suT8d2zYiFJ9+za79DVlIpuN4Ax L0aBa6iG5gTOybqy8zosRxrgbooHwh+46n8QfuqrOpjUC8P12iUeWPG0gXZ+jPo0chhY SH/Q== X-Gm-Message-State: APt69E1pE/ohGdoEKuA0Karym2bkHum6H24zYBSoHcoHu/Tw54EjkW79 p1qI9oXuhj8TAdmuiq0Ze3hhd6KunRcQHhrdK3lT1L/K X-Google-Smtp-Source: ADUXVKKc9CBdeWmYQBd3hu5dpq8bolY0VFw1eb1W3XMeENjaor90Mdptsm/A9b4FsEhe97h1vpGQ/Si9Stvsa0C1NLU= X-Received: by 2002:adf:d4c5:: with SMTP id w5-v6mr4961784wrk.185.1528466376053; Fri, 08 Jun 2018 06:59:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Fri, 8 Jun 2018 22:59:24 +0900 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000065c2ee056e21cfda" Archived-At: Subject: Re: [v6ops] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 13:59:41 -0000 --00000000000065c2ee056e21cfda Content-Type: text/plain; charset="UTF-8" NUD is not necessarily a good signal for this since by typically it is quiet for quite a while (30s with no traffic), and then suddenly gets impatient (if there is no response to at least one out of three packets 1 second apart, it declares a failure). It makes a lot of sense for a host that can use upper-layer hints from TCP or other transport-layer protocols, but not so much for a router. On Fri, Jun 8, 2018 at 5:51 PM Mikael Abrahamsson wrote: > > Hi, > > I'd like to bring attention to this draft. It's trying to solve a problem > when using IPoE and when to consider WAN being down (RFC7084), if there is > no physical link-down. > > I had an idea to use the ND state of the RA sending router, if ND to that > doesn't work for a certain amount of time (perhaps we can even use the > existing ND state and just monitor it), and if that indicates that > connectivity has been dead sufficiently long, kick down DHCP T1 timers and > try to renew, and if that is not successful, expire DHCP PD completly and > do everything RFC7084 says to do. > > Thoughts? > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000065c2ee056e21cfda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
NUD is not necessarily a good signal for this since by typ= ically it is quiet for quite a while (30s with no traffic), and then sudden= ly gets impatient (if there is no response to at least one out of three pac= kets 1 second apart, it declares a failure).

It makes a = lot of sense for a host that can use upper-layer hints from TCP or other tr= ansport-layer protocols, but not so much for a router.

On Fri, Jun 8, 2018 at 5:51 PM Mikae= l Abrahamsson <swmike@swm.pp.se&= gt; wrote:

Hi,

I'd like to bring attention to this draft. It's trying to solve a p= roblem
when using IPoE and when to consider WAN being down (RFC7084), if there is =
no physical link-down.

I had an idea to use the ND state of the RA sending router, if ND to that <= br> doesn't work for a certain amount of time (perhaps we can even use the =
existing ND state and just monitor it), and if that indicates that
connectivity has been dead sufficiently long, kick down DHCP T1 timers and =
try to renew, and if that is not successful, expire DHCP PD completly and <= br> do everything RFC7084 says to do.

Thoughts?


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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000065c2ee056e21cfda-- From nobody Fri Jun 8 07:05: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 CF2DE130E9D for ; Fri, 8 Jun 2018 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp9BbBluvApJ for ; Fri, 8 Jun 2018 07:05:35 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2685A130EAF for ; Fri, 8 Jun 2018 07:05:34 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B2D3542B78 for ; Fri, 8 Jun 2018 16:05:32 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A635042B71; Fri, 8 Jun 2018 16:05:32 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 97FD51AFFB; Fri, 8 Jun 2018 16:05:32 +0200 (CEST) Date: Fri, 8 Jun 2018 16:05:32 +0200 From: Gert Doering To: Lorenzo Colitti Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Message-ID: <20180608140532.GR1546@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.9.5 (2018-04-13) Archived-At: Subject: Re: [v6ops] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 14:05:39 -0000 Hi, On Fri, Jun 08, 2018 at 10:59:24PM +0900, Lorenzo Colitti wrote: > It makes a lot of sense for a host that can use upper-layer hints from TCP > or other transport-layer protocols, but not so much for a router. For a router, BFD seems to one of the few things that IETF seems to be able to agree on. Thus, implementations exist, and especially on the ISP side, vendors actually implement this somewhere distributed nowadays... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Jun 8 07:11: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 6E8A4130EB7 for ; Fri, 8 Jun 2018 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6CZAnb9AyB6k for ; Fri, 8 Jun 2018 07:11:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33EB126CC7 for ; Fri, 8 Jun 2018 07:11:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B08F5B1; Fri, 8 Jun 2018 16:11:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1528467105; bh=2WvIeKOKBoF5krmxEHlw94fKlJ2wG0bSZ7WTsg8LsQw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ys7aw1lBDY/f9jt3EvXJ7G/k8Ne0YWM7ygSKgPsdpaf9G96DIsjZT9/FBin+9f8pf OvP44JYtSMpRTet8ds8hokkVSNXxrgeIGCNVnnFz5KQCHLVIhxxmiRBIq9WWKC4z3x kPIRRBR45ssCfv7xPWLYJpCGJ9UHYETav3GMatLk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AE893B0; Fri, 8 Jun 2018 16:11:45 +0200 (CEST) Date: Fri, 8 Jun 2018 16:11:45 +0200 (CEST) From: Mikael Abrahamsson To: Gert Doering cc: "v6ops@ietf.org WG" In-Reply-To: <20180608140532.GR1546@Space.Net> Message-ID: References: <20180608140532.GR1546@Space.Net> 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] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 14:11:52 -0000 On Fri, 8 Jun 2018, Gert Doering wrote: > For a router, BFD seems to one of the few things that IETF seems to be > able to agree on. Thus, implementations exist, and especially on the > ISP side, vendors actually implement this somewhere distributed > nowadays... Are you aware of BFD implementations suited to be implemented on the HGW? I believe this is going to have to be run in echo mode without BFD needed to be supported on the ISP side. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jun 8 07:14: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 E430F130EB7 for ; Fri, 8 Jun 2018 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 jasEc1rKIRsb for ; Fri, 8 Jun 2018 07:14:42 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11559126CC7 for ; Fri, 8 Jun 2018 07:14:42 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 188-v6so1604532ita.5 for ; Fri, 08 Jun 2018 07:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jB7d8W7/BmiARWqZqdBblzDHDPhopj3sIIHrMJgQhoU=; b=RGS/OkNoWZUoYGibuKY1Mvl73KX9Mry6aOswlto2QBmZ8zpB0tEksKJjvryVI4xPKU 7eqMchoXfDNr7iHRp7gEdZxWeVbMNqI4sdoMWYjAvDwu7dySFFfqfhuBQlbEfPTgdSId ve9qvbTpY0KPPElWMMOSBEZ9sXLJ9jniUV9/rC/v6yqSTNKZJ9rYVmz7F7YzGhGXL3UT JGriQN7NDO67/+MjA1pD9Cj6j9/5YsrrfvsXO0qN36d7naScfHDOeZadvLVnuk2u5KQi cgtbzzD4n2qjQ5jL7gCdAVJXTZZrgjP4nXM+Of7ONiGxgS37vWwg0LMMo0eD9CNZDehR ByRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jB7d8W7/BmiARWqZqdBblzDHDPhopj3sIIHrMJgQhoU=; b=D5VWfN0h6LwIcYBqqq6H8vLxhqpM/w2200VGbXkviBRNrPljUulbtsD1XxuL+246EJ SV0+48g6lORHJwy+gsVrHeKu0yqUEiEQ0hWuxMLxF8We8voguX4nyEkBqV1WrhRU3MMQ 1ns3pfCe2GEbG01DR4l9O0WVSRfHFn+W2Ue5StqJW8oOooJBuNjgYXooXPf/EnDLLPUl 7efnFrAAdUKn5F8ySBmJeNrSgtxexyTfzRIAnEAn8KIa7astzsqGFv0ulevdW8qhL6SA wN+eM7hHhWx3y6ae4pPiTgU0ey18Goim80g/PCl0xBKIJudsKbBbIBEmhaH7lYIhfqdp C8BA== X-Gm-Message-State: APt69E3feid2S9qwwDa31bEHEf0xB64lafppzvvUr8mUH3V3sSjTDWty 2ds37brfnorUMwUC4XGzG1yqzZsg X-Google-Smtp-Source: ADUXVKI/8cZktB9kraeHebMEuxlbeGnKKrpfBSQL80Gsu5h+14OUEu3sT5klDcAMfyKNnrtlnPn53A== X-Received: by 2002:a24:a64d:: with SMTP id r13-v6mr1825047iti.124.1528467281320; Fri, 08 Jun 2018 07:14:41 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id i76-v6sm780933ita.33.2018.06.08.07.14.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 07:14:40 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id 188-v6so1604446ita.5 for ; Fri, 08 Jun 2018 07:14:40 -0700 (PDT) X-Received: by 2002:a24:e3ca:: with SMTP id d193-v6mr1806724ith.130.1528467280527; Fri, 08 Jun 2018 07:14:40 -0700 (PDT) MIME-Version: 1.0 References: <20180608140532.GR1546@Space.Net> In-Reply-To: <20180608140532.GR1546@Space.Net> From: Richard Patterson Date: Fri, 8 Jun 2018 15:14:29 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 14:14:44 -0000 On Fri, 8 Jun 2018 at 15:06, Gert Doering wrote: > For a router, BFD seems to one of the few things that IETF seems to be > able to agree on. Thus, implementations exist, and especially on the ISP > side, vendors actually implement this somewhere distributed nowadays... Sadly it's not widely supported on consumer routers, and full BFD would be quite heavy. Broadband Forum's TR-146 actually already discusses this issue and suggests the use of BFD echo. In the next version of this draft will reference TR-146, as well as prefer BFD echo as the health check mechanism if it's available. The IPOE_HEALTH DHCP Option interval and limit parameters will continue to be used, as will the behaviours defined once they're reached. -Richard From nobody Fri Jun 8 07:19: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 6F4D9130EBF for ; Fri, 8 Jun 2018 07:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSZzgYQ2ZgbQ for ; Fri, 8 Jun 2018 07:19:12 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03062130ED1 for ; Fri, 8 Jun 2018 07:19:12 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 35DDF42B78 for ; Fri, 8 Jun 2018 16:19:10 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2682E42B71; Fri, 8 Jun 2018 16:19:10 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 2386F1BB14; Fri, 8 Jun 2018 16:19:10 +0200 (CEST) Date: Fri, 8 Jun 2018 16:19:10 +0200 From: Gert Doering To: Mikael Abrahamsson Cc: Gert Doering , "v6ops@ietf.org WG" Message-ID: <20180608141910.GS1546@Space.Net> References: <20180608140532.GR1546@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZaDHQ4Sn1MqpFG35" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.9.5 (2018-04-13) Archived-At: Subject: Re: [v6ops] [Int-area] Intro to draft-patterson-intarea-ipoe-health-00 / RFC7084 wan down implications X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 14:19:20 -0000 --ZaDHQ4Sn1MqpFG35 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jun 08, 2018 at 04:11:45PM +0200, Mikael Abrahamsson wrote: > On Fri, 8 Jun 2018, Gert Doering wrote: >=20 > > For a router, BFD seems to one of the few things that IETF seems to be= =20 > > able to agree on. Thus, implementations exist, and especially on the= =20 > > ISP side, vendors actually implement this somewhere distributed=20 > > nowadays... >=20 > Are you aware of BFD implementations suited to be implemented on the HGW?= =20 > I believe this is going to have to be run in echo mode without BFD needed= =20 > to be supported on the ISP side. I haven't yet run any of this, but Google turned up a few hits https://github.com/dyninc/OpenBFDD "an open source implemnentation of the BFD protocol" https://github.com/thehajime/kbfd "ancient Linux BFD (...) implementation" [as a linux kernel module, plus a zebra/quagga patch to tap into kBFD for, BFD control and reporting] https://docs.cumulusnetworks.com/display/CL35/Bidirectional+Forwarding+Det= ection+-+BFD (only echo mode, page talks about FRRouting, frrouting.org does not=20 mention BFD though) BIRD seems to have a BFD module so - not sure if any of these are suitable for a memory- and CPU-starved CPE, but "BFD the protocol" isn't hard, the tricky bit would be "hook=20 into the state signalling logic of your router firmware"... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ZaDHQ4Sn1MqpFG35 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlsakFsACgkQ31bAZeTO f8W4GRAApTvQxVlO95XmR0m67JhQ9SaqPtA6U4envy2BhqWpToZDA1Y/P4PW11Tq 9GDx7AHBAequqPY5CpGElhTWkkNV1OQ9MyxDSnFI/hZm7ni3ok36WzqdoMTpJ+rr gZ0FQnVACTyoJQIcyoCtJBIT4ECFuAASSmyGS+1afIXQM3/DBsRZRBKAuX+qhvey GE6Jzr19pJ5sVhOkVbmuk1OrNXOQTADU3XdZuk05i1MIxhiaiHcdGhq9K+WKxyDq n8+4ceYhFHu/Nh/SBn5PsT3WF9wHwIWQv/0hvmJY7lTPEN+iF6L0yE2Bc7QEG0wS cV8u/UeU4z5h2gwlLpcQoic4v10Xlns/YG6qK1OZk42UN5NtCZM1FJNZEbFV+G2P cQqmE84VVxGMoUl7BEaqZY05sZ7MQyeSJr+jaUwCQCnWwjIporHKskMfS3P2Dv4+ XZHBO1jCaidwVq9lJD7HzSPE9OTC7CUTSL8GO0/L+BUwz/RmzZkQXE90swm1bxOH EpevNPvBBMpdvjVQuV6xDRsOLytZAJBOineawFJd9E6Hylck3Rn+UXsRU8SvQ1rM 2qDz6SP/eESI2Mcspp/wue3QIKeAJOx9aAjTzCt4JrRmBAIEDN95xRFpJnqsvG/V 9lDuTt3awWYSnjaz3BceBlYx2sIQF1bLNXn0GUTPtEGFI+rM4fs= =3Nod -----END PGP SIGNATURE----- --ZaDHQ4Sn1MqpFG35-- From nobody Fri Jun 8 17:59: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 796C3130DCE for ; Fri, 8 Jun 2018 17:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 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, T_HTML_ATTACH=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3__udwuAZbT for ; Fri, 8 Jun 2018 17:58:59 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EAE1277C8 for ; Fri, 8 Jun 2018 17:58:59 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id a22-v6so7408844pfo.12 for ; Fri, 08 Jun 2018 17:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:mime-version:subject:message-id:date:to; bh=CFcAaiqWk3QkMIFhK5Un+/6bqDB37gvNPQbGzKudt/E=; b=ij7UM3OiZBiaLwWo+kjB/T0bhp9m2VOrINftZsnhn5K31zC+NcMV/Sm6yFfSJh80lB G8+LG38k/iojMUk2Ve5DPAsx/lGHYddgJJgF8jCEJCVAn+Zg5FCC0+dCPDTvx3oDsWPC ap9MyPy3zTCyhdbsumLr61ZJoeQF7dtd6bHzDTORtJq4QpLYGG4I+ZbUXwdCKjopSNbE V/TaF+FhHXnhTKqfYzRlsKIiYxV8E4rD1NPAX9/Q4e7hBjQIqHN5YT1fDwinkUEt6iri vrc9KCxA09LyXdfmLofS+r5BUEce4KSRlFPpGYauIBMwBHsteJ69IQvLCURLmUq3lpWH wO4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:message-id :date:to; bh=CFcAaiqWk3QkMIFhK5Un+/6bqDB37gvNPQbGzKudt/E=; b=Lh1DDtXcegiS3Lv1kFVsbdtQkcsNmgvsE793wpKS5uZyV1F+AHGa/YqHZx8/DkglcB Tgs4/oeLVeAsSNk42EzSeNdNxGGKOIvL8946xlvMQkJbp9HgKx8IFu1RKbb2UWI7N2Vf 6QOPd+gUeJHnxyZFQNFPFdvgOJVPZu5N2V+afMa/yPtykas13E/T4YMKjEKtcbJIC1ad 7G8Hd5d2UN9LEoYNBjRY+l7IXldE/DkHuYipIq7Lpia717rKw+ez01/A4OwjcLxUV4TE gv44QhBj1Sb/e6cgZRh6kzjz66V5HGDo9WGQIF1Qx5d/xFxvX72bAt1b6e4ts3DHzwNK CP+Q== X-Gm-Message-State: APt69E3sIgRCTuqDbbFf99pS+KG0ElsWD9XQKIJruptyVHpJ9ygk2XHk ZaVxAxCHUPCs0crba4qbmcebPfZw X-Google-Smtp-Source: ADUXVKL3ThOGsCx15teQRbjH5zzoLX7qcY1kCPxoQERezXqrj8tqd5zdxfWIiSkiu0XsW+c6tDq18A== X-Received: by 2002:a63:7986:: with SMTP id u128-v6mr6905936pgc.273.1528505938785; Fri, 08 Jun 2018 17:58:58 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:35fa:5224:a971:5c5c? ([2600:8801:d004:600:35fa:5224:a971:5c5c]) by smtp.gmail.com with ESMTPSA id e189-v6sm21110327pfc.134.2018.06.08.17.58.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 17:58:57 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_20676D01-A4C3-4F14-919B-CB52F176FB60"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: V6ops Chairs Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> Date: Fri, 8 Jun 2018 17:58:56 -0700 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 00:59:02 -0000 --Apple-Mail=_20676D01-A4C3-4F14-919B-CB52F176FB60 Content-Type: multipart/mixed; boundary="Apple-Mail=_38D07DFE-F167-4A02-8BB0-C72BE03DE4C0" --Apple-Mail=_38D07DFE-F167-4A02-8BB0-C72BE03DE4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Permit me to comment on the IETF 102 agenda as it appears to be shaping = up. We have - an invited talk by George Michaelson of APNIC, who has been looking = at IPv6 traffic in world economies (You might find the observations surprising; hint, guess which = economy has the most IPv6 traffic? Which markets?) - draft-ietf-v6ops-transition-ipv4aas - draft-ietf-v6ops-ipv6rtr-reqs draft-ietf-v6ops-conditional-ras is under discussion in the IESG, and is = waiting for draft-ietf-rtgwg-enterprise-pa-multihoming before = proceeding. We have several other individual contributions, and have = discussed most of them on the list since IETF 101. The chairs don't see = a supporting interest level in them at this time. We have two slots, two hours each, at IETF 102. The chairs are right now = contemplating using one a slot for those three topics and perhaps a set = of lightning talks, and letting the second slot go. To change that, we need to see new drafts (e.g., new content) and = supporting list traffic. Your turn... --Apple-Mail=_38D07DFE-F167-4A02-8BB0-C72BE03DE4C0 Content-Disposition: attachment; filename=agenda-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="agenda-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

IESG: Waiting for Writeup

WG: Updated WG Document

Individual Submission: Updated

Fri Jun 8 10:36:42 2018

--Apple-Mail=_38D07DFE-F167-4A02-8BB0-C72BE03DE4C0-- --Apple-Mail=_20676D01-A4C3-4F14-919B-CB52F176FB60 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+AFAlsbJlAACgkQEhdRnd2G P+DyFg/9GNIxbPiPdeTx6f6uDCQrCSl95ZiXCZWY8bQ3/CickOcUdlDwyfbCuyPO /969wIbySnSQnpme2tvOziTVNcRXx23VT3I6+fALs3X5Yat+eXl7l7a9O23fgFm2 EaFN4gIdu4QxLLSLsTdmJBdcDKDaJs30z4oaXXPpmgVMI5osv0HViakxjwMXsaIt UAMRmXk100AHZJoiSP5OyYGXltXUnDuz63CZUUtXPNUR7GNQxOcJdAh69wdMhdsf eooRDuNRci0tkXP1bYN6A1NP7ajrasphpLZ3nMvPaR7MpC36NGhFkI8r2Ko/DQqo /7sV/fQTcfp6H7eZMLDY4zj5AM2x2YiLK/mGeSel3H8NCa9GT2fhaXK4UbEYi4Xg YlfTtlzHf9bqnYi+fElGywEcSfrymo/+uKQdYMtBrhtIlazw50VqNHBD9iVNgczp t857/sAugCoJnmTWOmCF6Ev58MjkMLzMijkN+ePp0Cwzc78iVT+FZJblxpQE7ltR kam/SwDAPkLaOlwTwmHsfDOdV6+nEYh3SAK/S6UEBHodduBy/P7Q/5HkW4BB0us5 bE0P+oOzIP9Mn08f85jLt7E6EnoGnz1reiOdU7VOS6fFGnp+69DV6i7BIPE/drMq u6dgohVIcgAQdnVu5UqIfpmZQU3Zf225QplrBuLU8AC8z2o/KXI= =Umao -----END PGP SIGNATURE----- --Apple-Mail=_20676D01-A4C3-4F14-919B-CB52F176FB60-- From nobody Sat Jun 9 04:58: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 692D2130E59 for ; Sat, 9 Jun 2018 04:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_7XmuuZuyhQ for ; Sat, 9 Jun 2018 04:58:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68846130E55 for ; Sat, 9 Jun 2018 04:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528545498; x=1529150298; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=xt+zIEyiTxgfNfs/DXAqO m1BDg0buZGRL0VYpN+jNyU=; b=MBGsQyuuU5jswJFKCipg8ZdPrKH3FUxMcwClK KouWVU4mK5Ft/ZGKZIIcgc9svMZhD27RY4ufsz0HCIzukhr6goQF1edSEvK+J0n4 Kx4Dp8dKlGoPMnRZBJmjUFldadaTpzqOPlOWih4K8BQYM3nt6gTbwfyM+fBm+10J BLmIs0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 09 Jun 2018 13:58:18 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 09 Jun 2018 13:58:18 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005784933.msg for ; Sat, 09 Jun 2018 13:58:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:d854:773:63e7:4f4a X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sat, 09 Jun 2018 13:58:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=169898ff15=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sat, 09 Jun 2018 13:58:17 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: Thread-Topic: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 11:58:24 -0000 H=EF=BB=BFi all, As a result of this week email exchange with Barbara, she mention about the= need to make sure, that any transition mechanism is enabled or not by the = CE, depending on the operator wish, which I agree. It seems to me that the best way for doing so is by ensuring that RFC8026 i= s used, so the S46 DHCPv6 option tells the CE what mechanisms (if any) that= the operator supports, and we have already text to say that in the documen= t. However, this option today only supports DS-Lite, lw4o6 and MAP-E/T. So, my question to the WG (and the chairs): It is possible (and the WG agree on that), to update RFC8026 (by means of a= short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-v6ops-= transition-ipv4aas) and instruct IANA to add a new code for 464XLAT?=20 I think this will be the cleaner and simpler way to do this. A more complex alternative will be to "force" the CE to actually "test" for= available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is being= used. Regards, Jordi =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Jun 9 08:24: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 D4509130E9E for ; Sat, 9 Jun 2018 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 sjEh9BXMCs9C for ; Sat, 9 Jun 2018 08:24:05 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE64130E93 for ; Sat, 9 Jun 2018 08:24:05 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id z24-v6so8047193pfe.7 for ; Sat, 09 Jun 2018 08:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ruld+fLHOR7CmQHHVh2f9KHmBcjLbNRql6M0yDg4ePs=; b=ouWipfZM9zwdIoU97CHRhj3DZrWdvQjQsYMuebhUUnQ7WUZVfixtD/n0b9+gubjFir aGT61L5R5CBgcB5xwEMZ6ciNlhw3jPDqrV1vMsEWCRjS0ANKPTBuxO+ifLOkxMrYYa63 XtjrdWwGeHzHTBAHp6SvvLgvTZlmDcYGnb2kevNEmvgKaw7xLR7xY7hupaem+XnBL77A 5G0fJGxDFBPaweLfIej6KjE2VnMvS1YVjh/4Hn/EN/Us0B13nMvfOvt8cWP8SlxRzhL4 m/1TtxTyXmQql+LxHnn4I9xmP5PHINQs/2ViafQDjUvW+8EzroxUrw48mvVjn/Mkxmj+ 1BPA== 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=Ruld+fLHOR7CmQHHVh2f9KHmBcjLbNRql6M0yDg4ePs=; b=UIJdx7wHiWafAp9hT5PHc3bn4tv0rH6Q5gEzlkRtma/CHLpl9ylnNyPTx5cugd0xdP t7wvZ+GAxOKZ3NRsRUR3lj1OuSrBCBUiiAl5ERwhYGmsLPlr7EedJo6UvtNB1DJCCVXT ubM1iueJ8mlx9AUAmc4MQ457xjEIekplFeInkQKcB1mipB9BQz3kL4lQCunKI36iW96X j1BmQJlqj2ozgZplyF7TaNrWURazhW765Wlo5CV2EE+MqnDcTnNjyGCsQ4XNa3a3HEiI cI4mKSEthk3B3SUX66GhdU9IBC+HGD+ASHdMsL40JiPKGgMrHBPfXVbCWxQwDF8Um2kV CcWg== X-Gm-Message-State: APt69E1vjrXPDCG/FQKkpNjpP1ErkOY96kLAr3MGyMsMwagNoyLNRBWO T/BWSsWJkZX/kkCPKFAgeviczzfd X-Google-Smtp-Source: ADUXVKJPU8/Uuk5H7oz02sOmbO6GDex5yHmI9mlsFWnjffbCRM6H0+2qkfaaRWDMmhfRk5Zodc+/zQ== X-Received: by 2002:a63:a042:: with SMTP id u2-v6mr9218269pgn.413.1528557844856; Sat, 09 Jun 2018 08:24:04 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:714b:a7fd:e79c:630c? ([2600:8801:d004:600:714b:a7fd:e79c:630c]) by smtp.gmail.com with ESMTPSA id z129-v6sm94014341pfb.108.2018.06.09.08.24.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 08:24:04 -0700 (PDT) From: Fred Baker Message-Id: <17DE59FD-882F-499B-9BDE-DD59D28BC00F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_809CCF8A-A357-4139-A032-73A7CAB20D6B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 9 Jun 2018 08:24:02 -0700 In-Reply-To: Cc: "v6ops@ietf.org list" To: JORDI PALET MARTINEZ References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 15:24:07 -0000 --Apple-Mail=_809CCF8A-A357-4139-A032-73A7CAB20D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You might take a look at https://github.com/LACNIC/natmeter for ideas. > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ = wrote: >=20 > H=EF=BB=BFi all, >=20 > As a result of this week email exchange with Barbara, she mention = about the need to make sure, that any transition mechanism is enabled or = not by the CE, depending on the operator wish, which I agree. >=20 > It seems to me that the best way for doing so is by ensuring that = RFC8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms = (if any) that the operator supports, and we have already text to say = that in the document. However, this option today only supports DS-Lite, = lw4o6 and MAP-E/T. >=20 > So, my question to the WG (and the chairs): >=20 > It is possible (and the WG agree on that), to update RFC8026 (by means = of a short "Update of RFC8026 for 464XLAT Support" section in = draft-ietf-v6ops-transition-ipv4aas) and instruct IANA to add a new code = for 464XLAT? >=20 > I think this will be the cleaner and simpler way to do this. >=20 > A more complex alternative will be to "force" the CE to actually = "test" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if = PCP is being used. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_809CCF8A-A357-4139-A032-73A7CAB20D6B 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+AFAlsb8RIACgkQEhdRnd2G P+CgbQ//RaJpPeX95qoGZxJiX0LSp2bRvr/Vn1a6mpbWSBLVKAJBikv7tqEKnAyO VGYZ2JKQPTExp9q73Cq2bZIm1+fqezCLG44E5BJOFIpuXFC488P871t2Kj7J73xC zYYDk6hR/ms+1F8vac8GIgD1Vv/PpeG7lht2jzyMgmoKjRX7GWwQTAOVzcvWL8/K l3Wn+TL496xpw8Nr63bWy4fzIqSbhiBZGfOzUYZ6sKvuPrSSPsp8OK3AT/Q4NX5x 3AeiFXS9HPUj4XO1yb/UInZ9fWeK08FF9POScLxEX3mSJmFNMigmbLclG3DS50GU taEOw4Rbr7u1sy8JHxEKedYS2U9fXtqRp+Q8rKpZJytnIey+2c8vx3s+t4TWvfWB 5wEQV5pI6PVAc8zTe/5SM35V/d0Y6VWZV9sM8ElXy7joluERtpnSOgOL45mKI6wl qH07oK6lnC+Xt9se3v4fVHy9UNyfvHZ6cKhzN74TFWZVmV+Ppx+u26e21oEAcjNh 26cGCvhaV9HzhZtt9Q/nrqdLsXBUcMjqIqxCf2jpQEYEXJ39QbokNdrgOpMDWEJo pqs2l9w8ic+CqtaSeb8ygN8KYEcE3U321Jnw4nDVqEWScR15bxYeddqQbf2Nwp0K mr2zTlsa9YGI05l7RgLzft9pJGUfFocGFUhdLhqQwld0YtNnNXs= =+X6N -----END PGP SIGNATURE----- --Apple-Mail=_809CCF8A-A357-4139-A032-73A7CAB20D6B-- From nobody Sat Jun 9 14:58: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 BD2E5127333; Sat, 9 Jun 2018 14:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 OvhMfygBkCnM; Sat, 9 Jun 2018 14:58:15 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC88120049; Sat, 9 Jun 2018 14:58:15 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id m5-v6so7962060pgd.3; Sat, 09 Jun 2018 14:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=0kFQ5UaxjG5yHE2IwRD2wyxkuwTAIZ2ihomQFUbLqr8=; b=iyg0rUP5XoUIUvf+nxRKFVzhrJXvakkKtDMTBiYOWi4KD7+vu809N6e+085UoFD9/g LKiTLK8z9a158maGwOssnV/cQSqSk0ii/9D7KnB0+TT0Qhh9Sd3WTPse0zD7PfT17vJf yaMmRYjO/i3AWyCUZ6E62wv4qINabR9abHfWwaLnmziFIBZxI0x4ngR83oSIyrEpmtso L7PTd279NTF5W7JYPSZXHeAYKh0CLP7DctfzVCCZsRgzLqSTmW3vSMaBIru6klBpnMP7 KwUPJKV8VLydIpCYwaLez8Y2xCP88cimkEofM1+DTL6iBKAzqJagtbJj4ARXXcUrdMCT Y3wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=0kFQ5UaxjG5yHE2IwRD2wyxkuwTAIZ2ihomQFUbLqr8=; b=Krl5kUhc05ZugPNxToBM4nctfwXLZKu4DwzmNJQQxWCVO8wf0UApoHyIPAQBF7QKAV rDjY3HsNkKKBPfrWOOBctAqJ3XPh1kZQSvOzAxmVapmvXhjBsbyttlYDDoXNnv2FANKl Jtw0qEUgE6Gq42cA7h+XsNQcJihHzibD1f6CDhENGSmajOYfmvgyh+QyBycUAcmJMfkl +6nyQSB1XlEiFdPjAQRBTf6W+UGv6CiHndl2gnQMX2JmiM8Vm68Wi0YW2KCCADSeHSKU dv4OJ1BAS2iP2UIYtxE1kMiLkxncd5zezinJozMGs32Hy6WqP2t0jgmrEkFqkhxrWDt1 2b9Q== X-Gm-Message-State: APt69E0dOomYMdhKNmqb1PVV+EUlvcQMdbVInujb0r1UIQvKvCPvWPuK y8e5Rqz8DJENFOvhoc296XzvpVYW X-Google-Smtp-Source: ADUXVKKUEU9QoTd16Z/OgxQZ9S/uW2S6t7q/7csBM5G/8fayGqZT2PQ15+qfUUcuBPMWzEx1KCvFSQ== X-Received: by 2002:a62:66c6:: with SMTP id s67-v6mr11460261pfj.139.1528581494463; Sat, 09 Jun 2018 14:58:14 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:249d:776b:21d2:c3ae? ([2600:8801:d004:600:249d:776b:21d2:c3ae]) by smtp.gmail.com with ESMTPSA id a11-v6sm30141598pgq.32.2018.06.09.14.58.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 14:58:13 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sat, 9 Jun 2018 14:58:12 -0700 Message-Id: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> Cc: intarea-chairs@ietf.org To: v6ops@ietf.org X-Mailer: iPad Mail (15F79) Archived-At: Subject: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 21:58:17 -0000 Looking for comments on draft-patterson-intarea-ipoe-health-00. The authors w= ould like to discuss it in v6ops at IETF 102 (Montreal). Do folks find it in= teresting/useful? The primary working group for this will be intarea, for reasons related to t= he charter. However, it would be useful to know that the problem is a genera= l one, and get comments on the proposed solution. Sent from my iPad= From nobody Sat Jun 9 20:40: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 8E9EA130DF7 for ; Sat, 9 Jun 2018 20:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkKLdvRWUbF5 for ; Sat, 9 Jun 2018 20:40:17 -0700 (PDT) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C923D130DF5 for ; Sat, 9 Jun 2018 20:40:17 -0700 (PDT) Received: by mail-pl0-x241.google.com with SMTP id w17-v6so10413938pll.9 for ; Sat, 09 Jun 2018 20:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HCJW2KdwotdBSZGA//E+NicG3i5khIzfIKWpI5dMujg=; b=q0orkEsyAhLJNOcompY+eUc81Jg4slxLpJ5d2riCT1TRPhLr5w+FStWd9OrIU1l0bP tgX9KI7JmJQ/QE8HWSVMvcIOIqgts+PWhntk3Xis+TkiISmTotLgmjfuz9hEBuiJbagd wLOOihiADj0gRS49RG+X3QrSTaifbjiL9pipAZ7H17rJuXJ5OCkzWXsBDlxMfZpY+YfB xWr+/S1X+VbHcpYsTFCqm2EUz37/Mj4Vag+sJPJceuMIGeCvkKIJ4EjT5HvP8Qd1H4ls F3OzC3FfoaFR+uFEYts0G6WC5JgSyIS7p8/hB2z5uVxar8yb3f+hEYy+z6MuPI+z7UTo Maaw== 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=HCJW2KdwotdBSZGA//E+NicG3i5khIzfIKWpI5dMujg=; b=gVPVJbS/H40zFDifLdX6UPFJiPhGWaz5ey7QH4G/s3RIdv9qsGzcCn1b4wA2JyReco HWDUigTBY1976IKPY9p6S56Rqtf2t6tjI7o7kIjAWKFi9ZBeoSFQXinIU8PKqTxO0/Cj Yw7MsbGqiDxuQsGjEnj9J5K+R65Xn/pDYZUnI0zXmg0tRwyYsho1lo2vDFFyFB25Dw9M PkTpG1IFVbUXDD95Xm7JKRDIDFA/+Xlyb5qUkOlZ6ayB0qrgHiX+Y0coC6TlNW9v9YYo VBMVmX/jfNo/bT/pEfaN23yKfDHDXCF49rtqTRy1g8iR19ekmcgf45f+kVvg8jAtc1E8 ikJA== X-Gm-Message-State: APt69E2/pTb5wiNd4ZqP78NaF/J1ahe7VoWbpg81BcUV9sMTSCrW0g32 Vhr7jmIm+oIn3UVtKBWUS+I= X-Google-Smtp-Source: ADUXVKIQdwMf3T3UePq56USVkSOxYaU4RhwQVrGuP/cLjITk1pSLiHSqBtmK26lkE5cRk6Ip+tJIVw== X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr13056882plf.47.1528602017345; Sat, 09 Jun 2018 20:40:17 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:20fb:4528:ff6c:c5c7? ([2600:8801:d004:600:20fb:4528:ff6c:c5c7]) by smtp.gmail.com with ESMTPSA id l67-v6sm67412396pfj.66.2018.06.09.20.40.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 20:40:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Sat, 9 Jun 2018 20:40:15 -0700 Cc: "v6ops@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> References: To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 03:40:20 -0000 I would ask one question. When the operator is using this in a managed servi= ce, of course the operator should be in control of it. Are we precluding usi= ng the CE in other than a managed service? I should think that in cases in w= hich it is *not* a managed service, the owner of the CE would be in control If it. Sent using a machine that autocorrects in interesting ways... > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: >=20 > H=EF=BB=BFi all, >=20 > As a result of this week email exchange with Barbara, she mention about th= e need to make sure, that any transition mechanism is enabled or not by the C= E, depending on the operator wish, which I agree. >=20 > It seems to me that the best way for doing so is by ensuring that RFC8026 i= s used, so the S46 DHCPv6 option tells the CE what mechanisms (if any) that t= he operator supports, and we have already text to say that in the document. H= owever, this option today only supports DS-Lite, lw4o6 and MAP-E/T. >=20 > So, my question to the WG (and the chairs): >=20 > It is possible (and the WG agree on that), to update RFC8026 (by means of a= short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-v6ops-t= ransition-ipv4aas) and instruct IANA to add a new code for 464XLAT?=20 >=20 > I think this will be the cleaner and simpler way to do this. >=20 > A more complex alternative will be to "force" the CE to actually "test" fo= r available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is being= used. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jun 10 01:23: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 4D463130E1F for ; Sun, 10 Jun 2018 01:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWFiZXFr-01y for ; Sun, 10 Jun 2018 01:23:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D271292F1 for ; Sun, 10 Jun 2018 01:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528618995; x=1529223795; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=4/16w2FY CR4c0l0Efm41EM2U7a2bVxdehjkMXHSFh9M=; b=rJLTJOuhcRiMTECnshM/ZE7O oPaNNlocE3FpkYi7yP95cg3+/LcCi3toDwep5bnB7zvTaQc3tXfR4fvLiaYZmf78 vOr8FB+mohIyIyPi7nJAXmjnVmnZ5zio5TUq8m2i+3IyoLnWgpnsHqrREJ4jiMIS FD7Ny4lXipjJF3azJW0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 10 Jun 2018 10:23:15 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 10 Jun 2018 10:23:15 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005785230.msg for ; Sun, 10 Jun 2018 10:23:15 +0200 X-MDRemoteIP: 2001:470:1f09:495:39f6:3470:159a:817 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 10 Jun 2018 10:23:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1699b32c36=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sun, 10 Jun 2018 10:23:13 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <39872B3E-3278-48A0-AEA0-E9CE0F6FA52D@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <17DE59FD-882F-499B-9BDE-DD59D28BC00F@gmail.com> In-Reply-To: <17DE59FD-882F-499B-9BDE-DD59D28BC00F@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 08:23:20 -0000 Yeah, I know this. Alejandro, from LACNIC is measuring NAT44 and NAT66. Pro= bably it could be adapted to detect NAT64, but I want to make it much simpl= er, and there is one more detail I've not mention in my email ... We may have an ISP having NAT64, but NOT wanting some customers to use it (= at least not by default), so with a DHCP option we facilitate that, as you = may have different DHCP options for different customers. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: s=C3=A1bado, 9 de junio de 2018, 17:24 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas You might take a look at https://github.com/LACNIC/natmeter for ideas. =20 > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: >=20 > H=EF=BB=BFi all, >=20 > As a result of this week email exchange with Barbara, she mention abo= ut the need to make sure, that any transition mechanism is enabled or not b= y the CE, depending on the operator wish, which I agree. >=20 > It seems to me that the best way for doing so is by ensuring that RFC= 8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if any= ) that the operator supports, and we have already text to say that in the d= ocument. However, this option today only supports DS-Lite, lw4o6 and MAP-E/= T. >=20 > So, my question to the WG (and the chairs): >=20 > It is possible (and the WG agree on that), to update RFC8026 (by mean= s of a short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-= v6ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT? >=20 > I think this will be the cleaner and simpler way to do this. >=20 > A more complex alternative will be to "force" the CE to actually "tes= t" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is= being used. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jun 10 01:26: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 8809B130E1F for ; Sun, 10 Jun 2018 01:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0-NBwPQ9huo for ; Sun, 10 Jun 2018 01:26:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890131292F1 for ; Sun, 10 Jun 2018 01:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528619185; x=1529223985; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=GyGW5yIu RcjL3EW3NIHVZtcAOn1NRSQ9oCcpSHEzKVw=; b=Nl5FuYpygcpSMhGq0GyBlYx2 0ptTA2W0yyJbPgN5YbPt6bmCvE9zyaJJbOrT9P6mYZPFdivyXjy/qOqw4BrTMECt g20c+AsYggXbFTi177f3yT32ihRwXxSABS578WqaDQYS85Pnu6uLWC2lW2HdfNwi cLtG6yqew4PB4AgVb1Y= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 10 Jun 2018 10:26:25 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 10 Jun 2018 10:26:25 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005785233.msg for ; Sun, 10 Jun 2018 10:26:25 +0200 X-MDRemoteIP: 2001:470:1f09:495:39f6:3470:159a:817 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 10 Jun 2018 10:26:25 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1699b32c36=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sun, 10 Jun 2018 10:26:21 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> In-Reply-To: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 08:26:30 -0000 You're right, and that's why we also will include a new requirement (this w= as also part of the email exchange with Barbara), in order to make sure tha= t is possible to turn on/off the mechanisms with a GUI or CLI, whatever is = available. This is already today an option with most of the CEs in the market for othe= r transition mechanisms, and this was not part of RFC7084, but here it is m= uch better we make it explicit. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: domingo, 10 de junio de 2018, 5:40 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas I would ask one question. When the operator is using this in a managed = service, of course the operator should be in control of it. Are we precludi= ng using the CE in other than a managed service? I should think that in cas= es in which it is *not* a managed service, the owner of the CE would be in = control If it. =20 Sent using a machine that autocorrects in interesting ways... =20 > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: >=20 > H=EF=BB=BFi all, >=20 > As a result of this week email exchange with Barbara, she mention abo= ut the need to make sure, that any transition mechanism is enabled or not b= y the CE, depending on the operator wish, which I agree. >=20 > It seems to me that the best way for doing so is by ensuring that RFC= 8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if any= ) that the operator supports, and we have already text to say that in the d= ocument. However, this option today only supports DS-Lite, lw4o6 and MAP-E/= T. >=20 > So, my question to the WG (and the chairs): >=20 > It is possible (and the WG agree on that), to update RFC8026 (by mean= s of a short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-= v6ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT?= =20 >=20 > I think this will be the cleaner and simpler way to do this. >=20 > A more complex alternative will be to "force" the CE to actually "tes= t" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is= being used. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jun 10 01:45: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 CA332130E21 for ; Sun, 10 Jun 2018 01:45:43 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 jBS0_pexrpyZ for ; Sun, 10 Jun 2018 01:45:39 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE461292F1 for ; Sun, 10 Jun 2018 01:45:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 76-v6so7054911itx.4 for ; Sun, 10 Jun 2018 01:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=smfJpiQnLJQ/fI/C1bqi1r+NnsX2g70uAnkKw297gKY=; b=paWl7kxZ55sL9TBSAmjG6QAXVkOtsP0eeyypKa7p1Qp7gxQYb0NShMsgNkzWI6dSea O9pv+n1mu56ATY86OnDrhOlZ9kYzA4XL9ZTeKoBOfx4Lgpm+oLhR1hguWW1saMIzwql8 77H+uFd/IQuDAXaxh9tO7y4vyMXhehI/992RQCa1tojcpk90q7n7KPebfXeG9AyLgVNz y2CHCrmAF/rCrJNiPi9F+RCsRdDTTEpV+Y2aZEgUrW0b0vtA5zwC7U6cedZUBvc43G5q 8CbQSP9ZTS9T/D/04ynLhj2KooKKiBiyitnoaLHBfuQdvcqxtoREnCqN+sfdsx65ROyw Dh3w== 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:content-transfer-encoding; bh=smfJpiQnLJQ/fI/C1bqi1r+NnsX2g70uAnkKw297gKY=; b=aUsQCDjtCktS7RvpJadlEgJWhtzCXkCxh2BMXo329mxCe2dMjP0t7GftNKsbzwdmyZ PSfwkSIGDKcs1srS9mXe23GLCG5Zc12mgXNiPzk/FoLj5GKLszFIk56NJFLnJrAkwJc+ qon+1bFV7mlHrZKBoZACJxFTuI6BZwc5tzS8tjx7wFVPCJPq+xZoEgVxQ10YquS3UEaW pJ8NBdoUoirE2PHrFi9NzPqZPaYQkQi7sBmOy9iuDgKfEcdB0bEjKd9iUGZt13UeowWx rNxIW768QBTKf4fleki+9QwD3NEBKAFQhS+L5FiBvsaoCQvisrH8OeXphTmR8+mBSeJU Z3Hg== X-Gm-Message-State: APt69E0JAhPcNSboqCN2z6XEYob0LbR70PpzYMII0AxwamdkuHFBTFK5 /j3/v44WgM3RbZs2VQZakliaeYhW X-Google-Smtp-Source: ADUXVKKsRLbRiFEmo8Fy3Ma107rKaEuehpipFep7bxVPD/sgRwAQv1xiihmmKpjAN898LiVhpiYBPg== X-Received: by 2002:a24:6041:: with SMTP id i62-v6mr7673097itc.153.1528620338907; Sun, 10 Jun 2018 01:45:38 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id z20-v6sm8739006ioj.36.2018.06.10.01.45.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 01:45:38 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id k3-v6so6508672iog.3 for ; Sun, 10 Jun 2018 01:45:38 -0700 (PDT) X-Received: by 2002:a6b:ce15:: with SMTP id p21-v6mr10334965iob.257.1528620337993; Sun, 10 Jun 2018 01:45:37 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> In-Reply-To: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> From: Richard Patterson Date: Sun, 10 Jun 2018 09:45:27 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Cc: jordi.palet=40consulintel.es@dmarc.ietf.org, Fred Baker Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 08:45:44 -0000 There are regulated markets that require providers to allow for BYO devices. Whilst BYO CE on an IPv4aaS network is probably a grey area, DHCP signalling would allow for a non-managed CE that supports the transition method to work without manual user configuration. I'm for this approach, to bring 464XLAT inline with the other methods. -Richard On Sun, 10 Jun 2018 at 04:40, Fred Baker wrote: > > I would ask one question. When the operator is using this in a managed se= rvice, of course the operator should be in control of it. Are we precluding= using the CE in other than a managed service? I should think that in cases= in which it is *not* a managed service, the owner of the CE would be in co= ntrol > If it. > > Sent using a machine that autocorrects in interesting ways... > > > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: > > > > H=EF=BB=BFi all, > > > > As a result of this week email exchange with Barbara, she mention about= the need to make sure, that any transition mechanism is enabled or not by = the CE, depending on the operator wish, which I agree. > > > > It seems to me that the best way for doing so is by ensuring that RFC80= 26 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if any) = that the operator supports, and we have already text to say that in the doc= ument. However, this option today only supports DS-Lite, lw4o6 and MAP-E/T. > > > > So, my question to the WG (and the chairs): > > > > It is possible (and the WG agree on that), to update RFC8026 (by means = of a short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-v6= ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT? > > > > I think this will be the cleaner and simpler way to do this. > > > > A more complex alternative will be to "force" the CE to actually "test"= for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is b= eing used. > > > > Regards, > > Jordi > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > 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 Sun Jun 10 02:03: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 38E96130E1C for ; Sun, 10 Jun 2018 02:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY2hvHj-aJZ3 for ; Sun, 10 Jun 2018 02:02:59 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E8412777C for ; Sun, 10 Jun 2018 02:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528621376; x=1529226176; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=NRWYbpmw W9IewO5fJ1EOpO34RdgnyVsu/EFncb8WKdQ=; b=m3GeOTYmdy6ymzQhLD8o8Niz 3mPxG4SViDjVIs6UongXMNWRjX3zz5HIeStG213uVVcw1rfvdSJ4wJkU9vvP8RNR se/8bg5Hs3e5+rk46H5WDpiII/Uxesj8VInBsb3gqeDjN64zjfHMckyRmU5SldeP F+SMSvSQBPJ5L4vhH+E= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 10 Jun 2018 11:02:56 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 10 Jun 2018 11:02:55 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005785240.msg for ; Sun, 10 Jun 2018 11:02:55 +0200 X-MDRemoteIP: 2001:470:1f09:495:39f6:3470:159a:817 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 10 Jun 2018 11:02:55 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1699b32c36=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sun, 10 Jun 2018 11:02:52 +0200 From: JORDI PALET MARTINEZ To: Richard Patterson , "v6ops@ietf.org list" Message-ID: <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@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] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 09:03:02 -0000 Thanks Richard, I'm guessing nobody will be against this, but I needed to a= sk, as this work is a WG item. Just to clarify my (procedural) question to the chairs or even AD. Long exp= lanation, but the question deserves it. RFC8026, unless I recall it incorrectly, was developed in softwires WG and = of course, being DHCPv6 options, was reviewed in DHCPv6 WG. The "long" titl= e of the document mention "softwire" because the actual options are mechani= sms developed within softwires WG (while 464XLAT was not). There are several mentions of softwires in the document, but my reading is = that the "softwire" word across the document is only "descriptive" not "pre= scriptive". I mean that the S46 priority option could be also used for something with i= s not "softwires". In fact, there is also an option (DHCPv4 over DHCPv6) wh= ich was developed within DHCPv6 WG and if you look into that document (RFC7= 341), it has no a single mention of "softwire" ... In other words. We could make an RFC8026-bis to: 1) Remove the mention of softwires and make it more generic for transition = DHCPv6 options 2) Add an option to support 464XLAT (and may be others) However, that may be a much slower path, and may be conflictive, because if= the work was done in Softwire WG, they may not like that now the document = is not used "only" for Softwires ... So, the alternative I'm asking is, from a procedural point of view: Can v6ops WG, just include an update in draft-ietf-v6ops-transition-ipv4aas= to add the option code for 464XLAT? I guess also Med and Ian, the original authors, may want to say something. = Clearly my intent is not to "break" in any way the actual document (on the = contrary, we are extending the usage and I guess this may be done by future= documents as well) and I don't think what I'm suggesting does it. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Richard Patterson Fecha: domingo, 10 de junio de 2018, 10:46 Para: "v6ops@ietf.org list" CC: Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas There are regulated markets that require providers to allow for BYO devices. Whilst BYO CE on an IPv4aaS network is probably a grey area, DHCP signalling would allow for a non-managed CE that supports the transition method to work without manual user configuration. =20 I'm for this approach, to bring 464XLAT inline with the other methods. =20 -Richard On Sun, 10 Jun 2018 at 04:40, Fred Baker wro= te: > > I would ask one question. When the operator is using this in a manage= d service, of course the operator should be in control of it. Are we preclu= ding using the CE in other than a managed service? I should think that in c= ases in which it is *not* a managed service, the owner of the CE would be i= n control > If it. > > Sent using a machine that autocorrects in interesting ways... > > > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: > > > > H=EF=BB=BFi all, > > > > As a result of this week email exchange with Barbara, she mention a= bout the need to make sure, that any transition mechanism is enabled or not= by the CE, depending on the operator wish, which I agree. > > > > It seems to me that the best way for doing so is by ensuring that R= FC8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if a= ny) that the operator supports, and we have already text to say that in the= document. However, this option today only supports DS-Lite, lw4o6 and MAP-= E/T. > > > > So, my question to the WG (and the chairs): > > > > It is possible (and the WG agree on that), to update RFC8026 (by me= ans of a short "Update of RFC8026 for 464XLAT Support" section in draft-iet= f-v6ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT= ? > > > > I think this will be the cleaner and simpler way to do this. > > > > A more complex alternative will be to "force" the CE to actually "t= est" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP = is being used. > > > > Regards, > > Jordi > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jun 10 04:16: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 C6C88130E30 for ; Sun, 10 Jun 2018 04:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 BxFM9oC1Y4YB for ; Sun, 10 Jun 2018 04:16:34 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC53126CC7 for ; Sun, 10 Jun 2018 04:16:34 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id v13-v6so17458539wrp.13 for ; Sun, 10 Jun 2018 04:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eXpKy7iV6yvPRrCA7cocak94nKogSq/WPb7Fl277yAk=; b=LsESjDsnxlH/Xx5sCu7oPisSyQ0Oyy4/sqikXsqvL7XZ/3v7TcuDoz4O7yDfFJ3TiL wZ1dZm/TJ+JpP+GO9m55NfL4djqQmQY0hi43ylfJMNkz3J2lAiLhbAeZqfBamJaus1Tz 6rw78yCpYqDppW2xl7RuHd1tO/8ddfj4fV1j/BooOrqc8sx3J1/yUpxvt/mAoOmXbdgV /uqakRN5aoY6t5p8/tmPLdrgX2BWpoLCxD+ox/lPDM3nRBbcU4mIFBX7cm+6TyCU8PYo UkONycBFXJTCRybgBgA8Gq36E5ZtIu5C6oCJurrsl7I600rHRMvEZIKKf7/WoZ+SgXEL Er4g== 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=eXpKy7iV6yvPRrCA7cocak94nKogSq/WPb7Fl277yAk=; b=EW8bOXMxXxyuInctw6LuXdSFNBadwtrqfG4iTcU+3k7LdQq75NahQx5kAsb/t1gQSE hdQ2KSbl0iNIELei1N2UMSqNqpUljJM+varWDfz9TmNOn31nA/8Q+G1YHvYj2niC+Lfh RersQDalPl2oAszsjgdCbAleO3xGBJJqxo1CQlW3mTxk2X3WsJHK0ESHzsTHMwDE5jwO rdZS/U15VJGKvfJQmG78ykiKX3FlYkkf6Q6Fjj9JVbOgHD98crurS7vjo+h+Qgfgaf2T TrN7fY5mMiZop8lt+ijBtI6pPEVT9bhybFmzC5MFj2avXeau7XTZL/2js9Q2B7mhbXSh PZqQ== X-Gm-Message-State: APt69E3pkfANBaPU7HwQsL7nMpeSqDw/7Dse4xL8PtCQlqypSIqNVobV f60kxQU7NUKHH/5sE42HKkUk1EG3ja/CO/IlnNtHXU5l X-Google-Smtp-Source: ADUXVKJ2vKUNpeknqhTaIzhBiOw2v8u25JwdGNorTwNBd+Fln+vnkyLZlxAOzTOxt64+zXD/EQEEfU83NzGAWc5dlao= X-Received: by 2002:adf:b02b:: with SMTP id f40-v6mr10427112wra.75.1528629392135; Sun, 10 Jun 2018 04:16:32 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> In-Reply-To: <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> From: Lorenzo Colitti Date: Sun, 10 Jun 2018 20:16:18 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: richard@helix.net.nz, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000e9bbe5056e47c351" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 11:16:36 -0000 --000000000000e9bbe5056e47c351 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTINEZ wrote: > So, the alternative I'm asking is, from a procedural point of view: > Can v6ops WG, just include an update in > draft-ietf-v6ops-transition-ipv4aas to add the option code for 464XLAT? > ISTR that the last time this was discussed in v6ops there was substantial opposition to a DHCPv6 option for 464xlat. To be honest, as a wireline ISP I don't see why you'd want to do 464xlat at all. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms. Its only advantage is that it's easy to deploy on mobile networks. If you do want to do 464xlat, it's much better to do discovery using RFC 7050. That way, hosts behind the CPE can discover the NAT64 by themselves, and do smart things like AAAA synthesis and DNSSEC, and also provide input to their happy eyeballs mechanisms that IPv4 is not native and thus may be less reliable. --000000000000e9bbe5056e47c351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 10= , 2018 at 6:03 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.i= etf.org> wrote:
So, the alte= rnative I'm asking is, from a procedural point of view:
Can v6ops WG, just include an update in draft-ietf-v6ops-transition-ipv4aas= to add the option code for 464XLAT?

IS= TR that the last time this was discussed in v6ops there was substantial opp= osition to a DHCPv6 option for 464xlat.

To be hone= st, as a wireline ISP I don't see why you'd want to do 464xlat at a= ll. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms. It= s only advantage is that it's easy to deploy on mobile networks.
<= div>
If you do want to do 464xlat, it's much better to do= discovery using RFC 7050. That way, hosts behind the CPE can discover the = NAT64 by themselves, and do smart things like AAAA synthesis and DNSSEC, an= d also provide input to their happy eyeballs mechanisms that IPv4 is not na= tive and thus may be less reliable.
--000000000000e9bbe5056e47c351-- From nobody Sun Jun 10 05:42: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 890D7130F49 for ; Sun, 10 Jun 2018 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG2MJUPnz45E for ; Sun, 10 Jun 2018 05:42:47 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::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 06FBC130E64 for ; Sun, 10 Jun 2018 05:42:47 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id y31-v6so17850520qty.9 for ; Sun, 10 Jun 2018 05:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=fleDJvPoytHH1Dzar+qO5gQiOp6JGafOGX3tMnoQaBM=; b=hwdL1KUlSFzhQIPrkwvoIvNWLBFFms1S0FBjJGFTIak0kRASTHhOC0KE+9Ro+jYAb7 /CJhc+p2kuFcVDAYZCI4wFHXZjZ7Js+mIYh9vITxR2f4vUTyJZ36LhjyV8tgdS29fCVF 23gZLDEQFTq5oSvdUydSUtcmrTPe/OMEqgHtZnwRfrTnVomk9A7VIkLlFeu/D5WvAU/D WrUpt2fQnjJIdsaBkwF1mP5aO2SXhZ7BhCfxX07JJgKhveVnVUvRip935xFoq3KuLWQv TvOmjI+VWMJK9HxjIBXIv85MZBXTEmIXKmfF5HSg0rWy6tWIuuhXt1t/j9g38vsaqOuQ Mw8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fleDJvPoytHH1Dzar+qO5gQiOp6JGafOGX3tMnoQaBM=; b=CANDuq1fPFvGDMGsLMen2Z/9/9Q7Zmf9QBRI3tVmv5u/uRHvRFks80gIHbGqNHVsyn 4helibdeuE+EQVvt+I1w064uLXPiAXv+tgsfCAFTgAZWu98MNI6a9nbMtqxHSxI8OGHx LRtMzV47OYUHac8DmOSSAyjzfCUB7f+e1H8OzFGbLM2AAH7bRdcrAKLJ3UjXK2ZEsFPl GyWdOL630wk2at+cRe1LBXOiFULX7+9Mvd6iEN56qq6uRqh6sgcUGNIT5OMAU/bAW4Zd 18yR/N820fbYFBFd+lIZaiHy+lctK0HnWgSLiMM+M9DuwB4/zLFL+ZJdh8PXot4F/hx8 TGQg== X-Gm-Message-State: APt69E3D+oyUtniKvmrd9uNTFhDIB4au7ywMAAqqiFL3QA1/6Aj/E/TJ dCnn3TBUWrXt3EU6a4D21QxyrJGl X-Google-Smtp-Source: ADUXVKK5fTHe3SEA5j/ZxJUq5csF2C8nbBpifm8WJzcoXcXt8ebHcugyXnDQ2+8jWF4mGIoD6GuB4w== X-Received: by 2002:a0c:c38e:: with SMTP id o14-v6mr11532562qvi.49.1528634565733; Sun, 10 Jun 2018 05:42:45 -0700 (PDT) Received: from MacBook-Pro-de-admin-alejandro.local ([2001:470:5:516:90f7:519f:66dd:641c]) by smtp.gmail.com with ESMTPSA id o68-v6sm20256979qkc.19.2018.06.10.05.42.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 05:42:45 -0700 (PDT) To: v6ops@ietf.org References: <17DE59FD-882F-499B-9BDE-DD59D28BC00F@gmail.com> <39872B3E-3278-48A0-AEA0-E9CE0F6FA52D@consulintel.es> From: Alejandro Acosta Message-ID: Date: Sun, 10 Jun 2018 08:42:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <39872B3E-3278-48A0-AEA0-E9CE0F6FA52D@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: es-ES Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 12:42:50 -0000 Hello,   Thanks for bringing the Natmeter project up.   You are right, we not measuring -yet- DNS64..., thanks for the idea, hope we come up with a clue in how to do this :-)..., just added to our radar. As a final comment we do have few more things about 1) CGN and 2) detecting prefix 192.0.0.0/29 on the client.    Willing to share the info. Alejandro, El 10/6/18 a las 04:23, JORDI PALET MARTINEZ escribió: > Yeah, I know this. Alejandro, from LACNIC is measuring NAT44 and NAT66. Probably it could be adapted to detect NAT64, but I want to make it much simpler, and there is one more detail I've not mention in my email ... > > We may have an ISP having NAT64, but NOT wanting some customers to use it (at least not by default), so with a DHCP option we facilitate that, as you may have different DHCP options for different customers. > > Regards, > Jordi > > > > -----Mensaje original----- > De: v6ops en nombre de Fred Baker > Fecha: sábado, 9 de junio de 2018, 17:24 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org list" > Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas > > You might take a look at https://github.com/LACNIC/natmeter for ideas. > > > On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ wrote: > > > > Hi all, > > > > As a result of this week email exchange with Barbara, she mention about the need to make sure, that any transition mechanism is enabled or not by the CE, depending on the operator wish, which I agree. > > > > It seems to me that the best way for doing so is by ensuring that RFC8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if any) that the operator supports, and we have already text to say that in the document. However, this option today only supports DS-Lite, lw4o6 and MAP-E/T. > > > > So, my question to the WG (and the chairs): > > > > It is possible (and the WG agree on that), to update RFC8026 (by means of a short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-v6ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT? > > > > I think this will be the cleaner and simpler way to do this. > > > > A more complex alternative will be to "force" the CE to actually "test" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is being used. > > > > Regards, > > Jordi > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Jun 10 06:07: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 9B3EC130E63 for ; Sun, 10 Jun 2018 06:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itcs62USsKWL for ; Sun, 10 Jun 2018 06:07:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7EA130E5B for ; Sun, 10 Jun 2018 06:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528636029; x=1529240829; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=fl01BDZfCvueF0FN+pJryk hEBbVZC0svN5ie20Jjt/Q=; b=LG4ba+XjDwTtWw85zrhMB9hnBP+DtYjSoJm4Lo I5AslyF6uEZrFk1U/PSZzRN25WsVkCMkafasqX9ckY3J8Wer2FpBrDDTkoaBuuPa 7PnrDYtwbo7AN+Osh4nik9lr4vnGH6SZJJ6fLabd4wnXpRoPv3nkmeLzzXUaNSPj 4S1b0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 10 Jun 2018 15:07:09 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 10 Jun 2018 15:07:08 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005785285.msg for ; Sun, 10 Jun 2018 15:07:07 +0200 X-MDRemoteIP: 2001:470:1f09:495:7180:2470:2de1:c914 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 10 Jun 2018 15:07:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1699b32c36=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sun, 10 Jun 2018 15:07:05 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Message-ID: <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611488025_230449903" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 13:07:16 -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_3611488025_230449903 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Lorenzo, =20 There are now many ISPs that have 464XLAT in the celular, and they will lik= e to use the same mechanism for the wireline. This is very convenient, if y= ou are using also an LTE interface on a wireline router as a backup of the = wired link. =20 I don=E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, in fact it is th= e most successful one, thanks in part to Android and Windows having impleme= nted it. =20 The point is not to discover the NAT64, this is easily done, as you indicat= ed by using RFC7050 or even with PCP. This is already described in the docu= ment. =20 The point is the ISP to be able to turn on or off each mechanism (464XLAT, = MAP, DS-Lite, etc.), and this is easily done if all them share the same DHC= P option. =20 I will like to understand if we still have such opposition, why. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: domingo, 10 de junio de 2018, 13:17 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTINEZ wrote: So, the alternative I'm asking is, from a procedural point of view: Can v6ops WG, just include an update in draft-ietf-v6ops-transition-ipv4aas= to add the option code for 464XLAT? =20 ISTR that the last time this was discussed in v6ops there was substantial o= pposition to a DHCPv6 option for 464xlat. =20 To be honest, as a wireline ISP I don't see why you'd want to do 464xlat at= all. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms. Its = only advantage is that it's easy to deploy on mobile networks. =20 If you do want to do 464xlat, it's much better to do discovery using RFC 70= 50. That way, hosts behind the CPE can discover the NAT64 by themselves, an= d do smart things like AAAA synthesis and DNSSEC, and also provide input to= their happy eyeballs mechanisms that IPv4 is not native and thus may be le= ss reliable. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611488025_230449903 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Lorenzo,

 

There are now many ISPs that have 464XLAT in the celular, and they will= like to use the same mechanism for the wireline. This is very convenient, = if you are using also an LTE interface on a wireline router as a backup of = the wired link.

 

I don= =E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, in fact it is the mos= t successful one, thanks in part to Android and Windows having implemented = it.

 

The point is not t= o discover the NAT64, this is easily done, as you indicated by using RFC705= 0 or even with PCP. This is already described in the document.

 

The point is the ISP to be able to= turn on or off each mechanism (464XLAT, MAP, DS-Lite, etc.), and this is e= asily done if all them share the same DHCP option.

<= o:p> 

I will like to understand if we still have suc= h opposition, why.


Regards,

=

Jordi<= /o:p>

 

 

=  

De: = v6ops <v6ops-bounces@ietf.o= rg> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.o= rg>
Fecha: domingo, 10 de junio de 2018, 13:17
Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC: "= v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops= ] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aa= s

 

On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTI= NEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

So, the alternative I'm asking is, from = a procedural point of view:
Can v6ops WG, just include an update in draf= t-ietf-v6ops-transition-ipv4aas to add the option code for 464XLAT?

=  

ISTR that the last time this was discussed = in v6ops there was substantial opposition to a DHCPv6 option for 464xlat.

<= o:p> 

To be honest, as a wireline ISP I don't see why you'd want to do 464x= lat at all. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms= . Its only advantage is that it's easy to deploy on mobile networks.

&= nbsp;

If you do want to do 464xlat, it's much better to do discovery using RFC 7= 050. That way, hosts behind the CPE can discover the NAT64 by themselves, a= nd do smart things like AAAA synthesis and DNSSEC, and also provide input t= o their happy eyeballs mechanisms that IPv4 is not native and thus may be l= ess reliable.

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611488025_230449903-- From nobody Sun Jun 10 13:09: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 758F4130ED4 for ; Sun, 10 Jun 2018 13:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c32Sv6y3MbbE for ; Sun, 10 Jun 2018 13:09:54 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 E296D130EE0 for ; Sun, 10 Jun 2018 13:09:54 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id a7-v6so8620945plp.3 for ; Sun, 10 Jun 2018 13:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NExDgC1y+CAjVgOJslfsxbN5YgCA8NbVvihSuz4P2iM=; b=LHJFZS201EZ4uKtBq6nvU+nO1qE3d98mTBlg/rpGsrzqdp9W3MtBrH2JjTSKoYv/j+ ctsw+G+6+dlxDT+tyMOOaRakVQ5EsdgIn5SEjHEE9N3zxhI0B9GqgouT9W6em8oKzE+8 N8zydS9/R6rjNmpNDItShdIvre6S43PwaKRvSiomLIU+UnagmKToWqlcF5VzyXBrHR5W 0+KvDg0yHpnTuiGs/kq5DtQ4kV7B1ZS0UVHseHlU+RYfGGvpFqwy8g53XJ4eufS+2tf8 g4S8f+omRENZlSGR11VnEhvXRdCCXpZbrpVDdvTj7/D0rgjp5PuKo6+aX1OmFCjXQPps iT7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NExDgC1y+CAjVgOJslfsxbN5YgCA8NbVvihSuz4P2iM=; b=QFfErQECjMNZkKi61WKcjgVvqulKMS/stVIiE5x9pghvY/fk261lK+rwjoU/H8EuLe fb6bw7xQaBMvTaqsKS62P/X30uEjsm8VUvGpxCWTHxsZigmaHFQRix5etMFp+cjmGB67 2tBlIGBKl8g9rXUHHOcQkJcK4UKeyqsk9cxZMwwgHGTjDpTjNm3g1S2QaIAjBmg4SFEU Ooln3FF9gI1yx3XNfut+TkNBuwrgmdbf0Dt2X0D8ble/Ur3r1Kd41LMx0/r27U6or11y Sq0gje1p5TkTysz9UuAhHuVy/xyCvCHOM7Ndl3xGINaQww0DY9HE+0YGMolEpMa1duCY QCjQ== X-Gm-Message-State: APt69E3o06S4fxcypo3yjx/7mwJ/ccV7/bIDZEkEib/lljSOECnfmP8S ei+aNnqbXRI3Brr0jTL+g09mxw== X-Google-Smtp-Source: ADUXVKJD2Bjw75k+OclbnQsRhcrnPJJOv8L7eELnGPPjwYSvUGU0/LljR0uKpL5pF+9EDefKyQR3UQ== X-Received: by 2002:a17:902:b28c:: with SMTP id u12-v6mr15391626plr.68.1528661394337; Sun, 10 Jun 2018 13:09:54 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id b83-v6sm44671590pfe.159.2018.06.10.13.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 13:09:53 -0700 (PDT) References: To: IPv6 Operations From: Brian E Carpenter Cc: Tomas Horacek , =?UTF-8?Q?Vost=c5=99ez_Radek?= X-Forwarded-Message-Id: Message-ID: <647c7516-2167-57b6-8ef8-c903b988e082@gmail.com> Date: Mon, 11 Jun 2018 08:09:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] A new IPv6-over-foo implementation report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 20:09:58 -0000 Hi, Another important step in IPv6 deployment has occurred. (The video is in Czech but the demo at the end is easy to understand.) Forwarded with permission. Brian -------- Forwarded Message -------- Subject: Re: RFC6214 Date: Wed, 6 Jun 2018 15:34:27 +0000 From: Tomas Horacek To: Bob Hinden CC: Brian Carpenter , Vost=C5=99ez Radek Hello Bob and Brian. We did it, we have implemented your RFC6214 ! Its 6.6. today, the day when IPv6 seminar takes place here in Prague: ht= tps://www.cesnet.cz/akce/ipv6-2018/. We have presented our RFC6214 implem= entation there with great success. The info, video is not yet available in English (only in Czech, sry). Video: https://www.youtube.com/watch?v=3DGTFXkXp_pig WebPage: https://www.rfc6214.com/ -> https://translate.google.com/transl= ate?hl=3Den&sl=3Dauto&tl=3Den&u=3Dhttps%3A%2F%2Frfc6214.com Have a nice day :). ________________________________ From: Tomas Horacek Sent: Wednesday, May 2, 2018 4:03 PM To: Bob Hinden Cc: Brian Carpenter Subject: Re: RFC6214 Thank you Bob for your quick reply. We are aware of the publishing date :-). S pozdravem / Best regards Tom=C3=A1=C5=A1 Hor=C3=A1=C4=8Dek [https://portal.totalservice.cz/AV_logo_all.jpg] LAN/WAN security supervisor M: +420 731 450 906 thoracek@totalservice.cz TOTAL SERVICE s.r.o. U Uranie 954/18 T: +420 270 002 811 170 00 Praha 7 Czech Republic www.totalservice.cz INFORMACE: Tato zpr=C3=A1va a p=C5=99ipojen=C3=A9 p=C5=99=C3=ADlohy jsou = ur=C4=8Deny v=C3=BDhradn=C4=9B v n=C3=AD uveden=C3=A9mu p=C5=99=C3=ADjemc= i a mohou obsahovat d=C5=AFv=C4=9Brn=C3=A9, osobn=C3=AD nebo chr=C3=A1n=C4= =9Bn=C3=A9 informace. Pokud jste tuto zpr=C3=A1vu obdr=C5=BEeli omylem ne= bo nedopat=C5=99en=C3=ADm, uv=C4=9Bdomte, pros=C3=ADm, odes=C3=ADlatele a= sma=C5=BEte tuto zpr=C3=A1vu. Tato zpr=C3=A1va nen=C3=AD n=C3=A1vrhem na= uzav=C5=99en=C3=AD smlouvy ani jeho p=C5=99ijet=C3=ADm, leda=C5=BEe je t= ak v textu v=C3=BDslovn=C4=9B uvedeno. P=C5=99ijet=C3=AD jak=C3=A9koliv n= ab=C3=ADdky nebo dokon=C4=8Den=C3=AD jedn=C3=A1n=C3=AD je =C3=BA=C4=8Dinn= =C3=A9 v=C3=BDhradn=C4=9B uzav=C5=99en=C3=ADm p=C3=ADsemn=C3=A9 smlouvy p= odepsan=C3=A9 statut=C3=A1rn=C3=ADm org=C3=A1nem nebo jinou opr=C3=A1vn=C4= =9Bnou =C4=8Di p=C3=ADsemn=C4=9B pov=C4=9B=C5=99enou osobou. ________________________________ From: Bob Hinden Sent: Wednesday, May 2, 2018 3:44 PM To: Tomas Horacek Cc: Bob Hinden; Brian Carpenter Subject: Re: RFC6214 Tomas, I am not aware of any implementations. Please look carefully at the date this RFC was published :-) Bob > On May 2, 2018, at 8:41 AM, Tomas Horacek wr= ote: > > > Hello there Robert, > I am very sorry to interrupt you. > > I just wanted to ask, is there yet real-life implementation of your RF= C6214 ? > > If so, can you please share a link or a contact to the person/group th= at implemented it ? > If not, can you please give a advice, if any ? > > Thank you for your time, patience, understanding. And thank you in adv= ance for your reply. > > :-) > > S pozdravem / Best regards > > Tom=C3=A1=C5=A1 Hor=C3=A1=C4=8Dek > > > LAN/WAN security supervisor > M: +420 731 450 906 > thoracek@totalservice.cz > > TOTAL SERVICE s.r.o. > > U Uranie 954/18 > T: +420 270 002 811 > 170 00 Praha 7 Czech Republic > www.totalservice.cz > INFORMACE: Tato zpr=C3=A1va a p=C5=99ipojen=C3=A9 p=C5=99=C3=ADlohy jso= u ur=C4=8Deny v=C3=BDhradn=C4=9B v n=C3=AD uveden=C3=A9mu p=C5=99=C3=ADje= mci a mohou obsahovat d=C5=AFv=C4=9Brn=C3=A9, osobn=C3=AD nebo chr=C3=A1n= =C4=9Bn=C3=A9 informace. Pokud jste tuto zpr=C3=A1vu obdr=C5=BEeli omylem= nebo nedopat=C5=99en=C3=ADm, uv=C4=9Bdomte, pros=C3=ADm, odes=C3=ADlatel= e a sma=C5=BEte tuto zpr=C3=A1vu. Tato zpr=C3=A1va nen=C3=AD n=C3=A1vrhem= na uzav=C5=99en=C3=AD smlouvy ani jeho p=C5=99ijet=C3=ADm, leda=C5=BEe j= e tak v textu v=C3=BDslovn=C4=9B uvedeno. P=C5=99ijet=C3=AD jak=C3=A9koli= v nab=C3=ADdky nebo dokon=C4=8Den=C3=AD jedn=C3=A1n=C3=AD je =C3=BA=C4=8D= inn=C3=A9 v=C3=BDhradn=C4=9B uzav=C5=99en=C3=ADm p=C3=ADsemn=C3=A9 smlouv= y podepsan=C3=A9 statut=C3=A1rn=C3=ADm org=C3=A1nem nebo jinou opr=C3=A1v= n=C4=9Bnou =C4=8Di p=C3=ADsemn=C4=9B pov=C4=9B=C5=99enou osobou. From nobody Mon Jun 11 00:39: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 9DD40130E11 for ; Mon, 11 Jun 2018 00:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAvoRn1FdMYl for ; Mon, 11 Jun 2018 00:39:55 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEE4130DFE for ; Mon, 11 Jun 2018 00:39:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5B7dqu2099217 for ; Mon, 11 Jun 2018 09:39:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DF0CE200D01 for ; Mon, 11 Jun 2018 09:39:52 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D5A86200BED for ; Mon, 11 Jun 2018 09:39:52 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5B7dpdC026198 for ; Mon, 11 Jun 2018 09:39:52 +0200 To: v6ops@ietf.org References: <647c7516-2167-57b6-8ef8-c903b988e082@gmail.com> From: Alexandre Petrescu Message-ID: <59049fa8-ff40-630e-9884-f58ea0e8e5a8@gmail.com> Date: Mon, 11 Jun 2018 09:39:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <647c7516-2167-57b6-8ef8-c903b988e082@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] A new IPv6-over-foo implementation report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 07:39:58 -0000 Hi, Congratulations to the designers and the realizers. It is potentially an extremely useful tool. The video explains in Czech how RFC6214 "IPv6 over Avian Carriers" is supposed to work. Then it shows implementation: computer creates Echo Request, prints a barcode (QR Code?), human attaches it to pigeon, and sends it up flying; it lands in another house, human detaches code, reads with smartphone, generates Reply, attaches to another pigeon, and sends back. People speak Czech, but there is a German flag at the landing site. The website rfc6214.com shows a packet dump and it is indeed IPv6. I wonder what was the communication range? a few meters, or kilometers? Thanks, Alex Le 10/06/2018 à 22:09, Brian E Carpenter a écrit : > Hi, > > Another important step in IPv6 deployment has occurred. > > (The video is in Czech but the demo at the end is easy to understand.) > > Forwarded with permission. > > Brian > > -------- Forwarded Message -------- > Subject: Re: RFC6214 > Date: Wed, 6 Jun 2018 15:34:27 +0000 > From: Tomas Horacek > To: Bob Hinden > CC: Brian Carpenter , Vostřez Radek > > > Hello Bob and Brian. > > > We did it, we have implemented your RFC6214 ! > > Its 6.6. today, the day when IPv6 seminar takes place here in Prague: https://www.cesnet.cz/akce/ipv6-2018/. We have presented our RFC6214 implementation there with great success. > > The info, video is not yet available in English (only in Czech, sry). > > > Video: https://www.youtube.com/watch?v=GTFXkXp_pig > > WebPage: https://www.rfc6214.com/ -> https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Frfc6214.com > > > Have a nice day :). > > ________________________________ > From: Tomas Horacek > Sent: Wednesday, May 2, 2018 4:03 PM > To: Bob Hinden > Cc: Brian Carpenter > Subject: Re: RFC6214 > > > > Thank you Bob for your quick reply. > > > We are aware of the publishing date :-). > > > S pozdravem / Best regards > > > Tomáš Horáček > [https://portal.totalservice.cz/AV_logo_all.jpg] > > LAN/WAN security supervisor > > M: +420 731 450 906 > > > > thoracek@totalservice.cz > > > > TOTAL SERVICE s.r.o. > > > > > U Uranie 954/18 > > T: +420 270 002 811 > > > 170 00 Praha 7 Czech Republic > > www.totalservice.cz > > > INFORMACE: Tato zpráva a připojené přílohy jsou určeny výhradně v ní uvedenému příjemci a mohou obsahovat důvěrné, osobní nebo chráněné informace. Pokud jste tuto zprávu obdrželi omylem nebo nedopatřením, uvědomte, prosím, odesílatele a smažte tuto zprávu. Tato zpráva není návrhem na uzavření smlouvy ani jeho přijetím, ledaže je tak v textu výslovně uvedeno. Přijetí jakékoliv nabídky nebo dokončení jednání je účinné výhradně uzavřením písemné smlouvy podepsané statutárním orgánem nebo jinou oprávněnou či písemně pověřenou osobou. > > > ________________________________ > From: Bob Hinden > Sent: Wednesday, May 2, 2018 3:44 PM > To: Tomas Horacek > Cc: Bob Hinden; Brian Carpenter > Subject: Re: RFC6214 > > Tomas, > > I am not aware of any implementations. > > Please look carefully at the date this RFC was published :-) > > Bob > >> On May 2, 2018, at 8:41 AM, Tomas Horacek wrote: >> >> >> Hello there Robert, >> I am very sorry to interrupt you. >> >> I just wanted to ask, is there yet real-life implementation of your RFC6214 ? >> >> If so, can you please share a link or a contact to the person/group that implemented it ? >> If not, can you please give a advice, if any ? >> >> Thank you for your time, patience, understanding. And thank you in advance for your reply. >> >> :-) >> >> S pozdravem / Best regards >> >> Tomáš Horáček >> >> >> LAN/WAN security supervisor >> M: +420 731 450 906 >> thoracek@totalservice.cz >> >> TOTAL SERVICE s.r.o. >> >> U Uranie 954/18 >> T: +420 270 002 811 >> 170 00 Praha 7 Czech Republic >> www.totalservice.cz >> INFORMACE: Tato zpráva a připojené přílohy jsou určeny výhradně v ní uvedenému příjemci a mohou obsahovat důvěrné, osobní nebo chráněné informace. Pokud jste tuto zprávu obdrželi omylem nebo nedopatřením, uvědomte, prosím, odesílatele a smažte tuto zprávu. Tato zpráva není návrhem na uzavření smlouvy ani jeho přijetím, ledaže je tak v textu výslovně uvedeno. Přijetí jakékoliv nabídky nebo dokončení jednání je účinné výhradně uzavřením písemné smlouvy podepsané statutárním orgánem nebo jinou oprávněnou či písemně pověřenou osobou. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jun 11 05:37: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 395CE130FC4 for ; Mon, 11 Jun 2018 05:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 uozMDXLRsVQ7 for ; Mon, 11 Jun 2018 05:37:22 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D54130E3D for ; Mon, 11 Jun 2018 05:37:21 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id k16-v6so20251155wro.0 for ; Mon, 11 Jun 2018 05:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aTLEuoFk7B0FwAByv4RfLgpJ4ToejAEEFZ71VzCeQGY=; b=OhbIp70g+z878T1e7OqVetg1QFitjmycDTZ3AsqrS2ndhxQ2ExPnyPd2azyqG/I2L7 kPzXFxKvNBRCLaObpCAZIMGtRBhN0V4zpOkka0nyh7mejYkAO+eLrsvDNiCMZyXci3V+ JQZUMz8hrRBa9XiJ4IqMijl7SXLZmlqGrHLHqZo8TBQ7Ij5lzzwP2PJXkJzUSwEEOEQu yER/7ttl2MXqN4PusxkG8MNV5NaFufPK9r9yqbT3GuQAtwJCMkN8/Orhjye33fqYRIQb 4EqmlmTMFVat8HnxhttLJ/TY6ydLYNbSQOo1bdGqacleyHRcjRiw6rdfV7QjvAQYgdF8 vYVA== 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=aTLEuoFk7B0FwAByv4RfLgpJ4ToejAEEFZ71VzCeQGY=; b=LMzSFlKV+Rn188VdUCgCDpp7NYXHbA/cayIctd8RWG8059HiLGOYfkiidyfqzH+AG+ 4P5HyUIJtdCIIuM/3YQSfGelgS/STjam8teXwdgTN7yqWFYFEALY9KKnxbT4RwJzRTL7 /J2aNOL32+Vekaq6VzoNaYffqLueT/N/rc2BDcZOrSyuOCw53pDUtRPxbxA0y3YKnGMh 5E2fXi0BoqswobYIAnnmm8nsm6Xnc5UTnpmvSbS/9SDCQA6G+fJ4P7kpd66VdENAzfb3 oJLiwz8yJC/HSLJxRBUCrBPNcq2hDV5iMEssgsDkldwT70JGAaCgN6Q1a93XR7u17uB2 vmwQ== X-Gm-Message-State: APt69E3/XRfo667vJwgzLETKKmeH2WDbMsyAEWw7tivbW+OS9WarnVng qB0zQJIncyiZIIlyw1SERGn12JXwz/w8eHi+YX29vQ== X-Google-Smtp-Source: ADUXVKI48k8NcBKBDibuec/QeD+LpjewEzaumFkls3+fBtTqJ2r4OqcAt0mJFsZZqRWMGcqK7m2+NwIqxh/iM4lRqQU= X-Received: by 2002:adf:d08b:: with SMTP id y11-v6mr13287820wrh.152.1528720639993; Mon, 11 Jun 2018 05:37:19 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-Reply-To: <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> From: Lorenzo Colitti Date: Mon, 11 Jun 2018 21:37:07 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000b59a97056e5d02aa" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 12:37:25 -0000 --000000000000b59a97056e5d02aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 10, 2018 at 10:07 PM JORDI PALET MARTINEZ wrote: > There are now many ISPs that have 464XLAT in the celular, and they will > like to use the same mechanism for the wireline. This is very convenient, > if you are using also an LTE interface on a wireline router as a backup o= f > the wired link. > Then they can use RFC 7050, which already works today both in their networks and in client implementations. > I don=E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, in fact it is = the most > successful one, thanks in part to Android and Windows having implemented = it. > It's successful in mobile. It isn't successful in wireline, and IMO it does not deserve to be since there are much better transition mechanisms. > The point is the ISP to be able to turn on or off each mechanism (464XLAT= , > MAP, DS-Lite, etc.), and this is easily done if all them share the same > DHCP option. > The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS servers that don't do DNS64 translation. > I will like to understand if we still have such opposition, why. > Because it requires additional standards work, engineering work and implementation complexity to achieve something that is already possible today using RFC 7050. --000000000000b59a97056e5d02aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 10= , 2018 at 10:07 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> w= rote:

There are now many ISPs that have 464XLAT in the celular, a= nd they will like to use the same mechanism for the wireline. This is very = convenient, if you are using also an LTE interface on a wireline router as = a backup of the wired link.


=
Then they can use RFC 7050, which already works today both in their ne= tworks and in client implementations.
=C2=A0

I don=E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, i= n fact it is the most successful one, thanks in part to Android and Windows= having implemented it.


It's successful in mobile. It isn't successful in wireline, and IM= O it does not deserve to be since there are much better transition mechanis= ms.
=C2=A0

The point is the ISP = to be able to turn on or off each mechanism (464XLAT, MAP, DS-Lite, etc.), = and this is easily done if all them share the same DHCP option.


The ISP can easily turn off 464xla= t via DHCPv6 today: just provide DNS servers that don't do DNS64 transl= ation.
=C2=A0=C2=A0

I will like to un= derstand if we still have such opposition, why.


Because it requires additional standards work, = engineering work and implementation complexity to achieve something that is= already possible today using RFC 7050.
--000000000000b59a97056e5d02aa-- From nobody Mon Jun 11 05:55: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 936D313106A for ; Mon, 11 Jun 2018 05:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRCxGh_pCW8T for ; Mon, 11 Jun 2018 05:55:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14AF130FDF for ; Mon, 11 Jun 2018 05:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528721728; x=1529326528; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=HGVbFt5r1iuT9BqQPvIEc4 RvkZ1QEP8d5rABwq0I8c0=; b=sPzXYkr+vDoEnKLYzBnBjmHO1h3Re+EpRuwr77 0cbn0Kp8/zqf4f6lp/ff++vuK834UxKr7Qs2E7X/V4yfxXsW4YJiAolkRiY9G9qK VIr79r6XHhd/m2b/pJhWuD6Tzsq5MupfZpVC4Fw+BCe3GPLbgVqLckRpGoWLyfDH h00F8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Jun 2018 14:55:28 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 11 Jun 2018 14:55:27 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786051.msg for ; Mon, 11 Jun 2018 14:55:26 +0200 X-MDRemoteIP: 2001:470:1f09:495:3134:c630:857b:9b5 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 11 Jun 2018 14:55:26 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1700769604=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 11 Jun 2018 14:55:26 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611573726_611820195" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 12:55:40 -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_3611573726_611820195 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable There are now many ISPs that have 464XLAT in the celular, and they will lik= e to use the same mechanism for the wireline. This is very convenient, if y= ou are using also an LTE interface on a wireline router as a backup of the = wired link. =20 Then they can use RFC 7050, which already works today both in their network= s and in client implementations. =20 I don=E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, in fact it is th= e most successful one, thanks in part to Android and Windows having impleme= nted it. =20 It's successful in mobile. It isn't successful in wireline, and IMO it does= not deserve to be since there are much better transition mechanisms. =20 Each network is a different case, and in many cases 464XLAT is much better = than any other mechanism in wireline, WISP, etc. Every ISP has their own vi= ew/decision on this. We just need to provide the tools to make it feasible. =20 The point is the ISP to be able to turn on or off each mechanism (464XLAT, = MAP, DS-Lite, etc.), and this is easily done if all them share the same DHC= P option. =20 The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS serv= ers that don't do DNS64 translation. =20 No, that is not a solution, at least not for the scope of what is needed in= this document. You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so that wil= l not work. Also, users tend to change their DNS servers, so once more this doesn=E2=80= =99t work. We need something very simple to explicitly tell the CE =E2=80=9Cyou MUST E= NABLE/DISABLE the CLAT=E2=80=9D. Fortunately this is already there: RFC8026, we just need a new option code. =20 I will like to understand if we still have such opposition, why. =20 Because it requires additional standards work, engineering work and impleme= ntation complexity to achieve something that is already possible today usin= g RFC 7050. =20 I believe you=E2=80=99re misunderstanding what is needed here. I=E2=80=99m = not talking about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the NAT64 pref= ix or server. This is already done by RFC7050 or RFC7225 (PCP).=20 It is not a NEW DHCPv6 protocol. Is a new option code in an existing protoc= ol (RFC8026). There is nothing new to develop. We just need to tell IANA = =E2=80=9Cin addition to the already defined option codes for DS-LITE, MAP, = etc., define one for 464XLAT=E2=80=9D. =20 What we have now is: =20 +-------------+--------------------+-----------+ | Option Code |=C2=A0=C2=A0 S46 Mechanism=C2=A0=C2=A0=C2=A0 | Reference | +-------------+--------------------+-----------+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 DS-Lite=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6334] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 88=C2=A0=C2=A0=C2=A0=C2=A0 | DHCPv4 over DH= CPv6 | [RFC7341] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 94=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 MAP-E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RF= C7598] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 95=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 MAP-T=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0| [RF= C7598] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 96=C2=A0=C2=A0=C2=A0=C2=A0 | Lightweight 4o= ver6 | [RFC7598] | +-------------+--------------------+-----------+ =20 And what we need is to add a code for 464XLAT, so it will become: =20 +-------------+--------------------+-----------+ | Option Code |=C2=A0=C2=A0 S46 Mechanism=C2=A0=C2=A0=C2=A0 | Reference | +-------------+--------------------+-----------+ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 DS-Lite=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6334] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 88=C2=A0=C2=A0=C2=A0=C2=A0 | DHCPv4 over DH= CPv6 | [RFC7341] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 94=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 MAP-E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RF= C7598] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 95=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 MAP-T=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0| [RF= C7598] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 96=C2=A0=C2=A0=C2=A0=C2=A0 | Lightweight 4o= ver6 | [RFC7598] | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xy=C2=A0=C2=A0=C2=A0=C2=A0 | =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0464XLAT=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| [RFC6877] | +-------------+--------------------+-----------+ =20 I believe this is a very frequent usage of new option codes, for existing p= rotocols, via the IANA section. =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611573726_611820195 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

There are now many= ISPs that have 464XLAT in the celular, and they will like to use the same = mechanism for the wireline. This is very convenient, if you are usin= g also an LTE interface on a wireline router as a backup of the wired link.=

=  

Then they can use RFC 7050, which already works today both in their netwo= rks and in client implementations.

 

= I don=E2=80=99t agree is the worst IPv4-in-IPv6 mechanism, in fact it is th= e most successful one, thanks in part to Android and Windows having impleme= nted it.

 

It's successful in mobile. It isn't succ= essful in wireline, and IMO it does not deserve to be since there are much = better transition mechanisms.

 

Each network = is a different case, and in many cases 464XLAT is much better than any othe= r mechanism in wireline, WISP, etc. Every ISP has their own view/decision o= n this. We just need to provide the tools to make it feasible.

 

The point is the ISP to be able to turn on or off each= mechanism (464XLAT, MAP, DS-Lite, etc.), and this is easily done if all th= em share the same DHCP option.

=

 

The ISP can easily= turn off 464xlat via DHCPv6 today: just provide DNS servers that don't do = DNS64 translation.

 = ;

No, that is not a soluti= on, at least not for the scope of what is needed in this document.

You can run 464XLAT wi= thout DNS64, so to avoid breaking DNSSEC, so that will not work.=

Also, users tend to chan= ge their DNS servers, so once more this doesn=E2=80=99t work.

We need something very simp= le to explicitly tell the CE =E2=80=9Cyou MUST ENABLE/DISABLE the CLAT=E2= =80=9D.

Fortun= ately this is already there: RFC8026, we just need a new option code.<= /o:p>

  

I will like to underst= and if we still have such opposition, why.

&= nbsp;

Because it requires additional standards work, engineering work and implem= entation complexity to achieve something that is already possible today usi= ng RFC 7050.

 

I believe you=E2=80=99re misunderstanding what is needed here. I= =E2=80=99m not talking about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the= NAT64 prefix or server. This is already done by RFC7050 or RFC7225 (PCP). =

It is not a N= EW DHCPv6 protocol. Is a new option code in an existing protocol (RFC8026).= There is nothing new to develop. We just need to tell IANA =E2=80=9Cin add= ition to the already defined option codes for DS-LITE, MAP, etc., define on= e for 464XLAT=E2=80=9D.

 

What we have now is:

 

+-------------+--------------------+--= ---------+

| Option Code |=C2=A0=C2=A0 S46 Mechanism=C2= =A0=C2=A0=C2=A0 | Reference |

+-------------+----------= ----------+-----------+

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 64=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DS-Lite=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6334] |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 88=C2= =A0=C2=A0=C2=A0=C2=A0 | DHCPv4 over DHCPv6 | [RFC7= 341] |

|=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 94=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAP= -E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RF= C7598] |

|=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 95=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = MAP-T=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0| [RFC7598] |

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 96=C2=A0=C2=A0=C2=A0=C2=A0 | Lightweight 4over6 | [RFC7598] |

+----= ---------+--------------------+-----------+

 

And what we need is to add a code for= 464XLAT, so it will become:

 

+-------------+------------------= --+-----------+

| Option Code |=C2=A0=C2=A0 S46 Mechani= sm=C2=A0=C2=A0=C2=A0 | Reference |

+-------------+----= ----------------+-----------+

|=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 64=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DS-Lite= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC6334] |

|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 88=C2=A0=C2=A0=C2=A0=C2=A0 | DHCPv4 over DHCPv6 | [RFC7341] |

|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 94=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 MAP-E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC7598] |

|=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 95=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 MAP-T=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0| [RFC7598] |

|=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 96=C2=A0=C2=A0=C2=A0=C2=A0 | Lightweight 4over6 | = [= RFC7598] |

= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xy=C2=A0=C2=A0=C2=A0=C2=A0 | =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0464XLAT=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| [= RFC6877] |

<= p class=3DMsoNormal style=3D'background:white;word-break:break-all'>+-= ------------+--------------------+-----------+

 

I believe this is a ver= y frequent usage of new option codes, for existing protocols, via the IANA = section.

=  

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611573726_611820195-- From nobody Mon Jun 11 06:08:10 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 9C7E6130E3D for ; Mon, 11 Jun 2018 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACARELq2iS3h for ; Mon, 11 Jun 2018 06:08:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596D3130DC8 for ; Mon, 11 Jun 2018 06:08:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fSMYD-0000FrC; Mon, 11 Jun 2018 15:08:01 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-reply-to: Your message of "Mon, 11 Jun 2018 14:55:26 +0200 ." Date: Mon, 11 Jun 2018 15:08:00 +0200 Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 13:08:08 -0000 > I believe you're misunderstanding what is needed here. I'm not > talking about a new DHCPv6 way to "find" the NAT64 prefix or > server. This is already done by RFC7050 or RFC7225 (PCP). If you can detect the presence of NAT64 using either RFC7050 or RFC7225 then why do you need a separate DHCPv6 option? From nobody Mon Jun 11 06:15: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 C6850130E3D for ; Mon, 11 Jun 2018 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkuHt-MEt71P for ; Mon, 11 Jun 2018 06:15:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347781294D0 for ; Mon, 11 Jun 2018 06:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528722923; x=1529327723; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=EMFAo9bs 3j/J4qNMB+tPK74Yz+8CKe+xDtTNe+E4OCY=; b=GzzlG3UWvcERz8FJup0o8lfM H4WiMb7E5Zd4baibLQbrlAPIShP/ZJfVxg9xM/gYzSWz4ISYfJtxL28fln7SW5Xj wc81LONenL38htGAduBbgdi27f9vvya+xFKwfbu2gsj9CSjvInTEF3hOP/qkzyCs +prmAZ8yvseb+nCcT5M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Jun 2018 15:15:23 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 11 Jun 2018 15:15:22 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786079.msg for ; Mon, 11 Jun 2018 15:15:21 +0200 X-MDRemoteIP: 2001:470:1f09:495:3134:c630:857b:9b5 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 11 Jun 2018 15:15:21 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1700769604=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 11 Jun 2018 15:15:18 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 13:15:28 -0000 Hi Philip, The point is not to detect the NAT64, is to tell the CE "use it or not". You may have a network with some customers that you want to use 464XLAT, ot= hers only IPv6, others dual-stack. If we use a detection mechanism based in RFC7050 and RFC7225, the CE must t= ry both. Even more, if in the future there is another way defined for the N= AT64, the CE also need to try that. But the worst is that you're forcing all the customers the same way. This i= s what it was discussed a few days ago. The ISP want to have different cust= omers using different transition mechanisms, because he may be in the middl= e of a transition, or the customers have different "properties", etc., and = we need to allow it. Again, is not a new DHCP option. Is a new "option code" for the RFC8026. No= t a new "DHCP" mechanism to develop. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: en nombre de Philip Homburg Fecha: lunes, 11 de junio de 2018, 15:08 Para: CC: JORDI PALET MARTINEZ Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas=20 > I believe you're misunderstanding what is needed here. I'm not > talking about a new DHCPv6 way to "find" the NAT64 prefix or > server. This is already done by RFC7050 or RFC7225 (PCP). =20 If you can detect the presence of NAT64 using either RFC7050 or RFC7225= then why do you need a separate DHCPv6 option? =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 11 06:48: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 32DB4130E51 for ; Mon, 11 Jun 2018 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1gYYVKY9M-6 for ; Mon, 11 Jun 2018 06:48:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561BC1294D0 for ; Mon, 11 Jun 2018 06:48:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fSNAr-0000FDC; Mon, 11 Jun 2018 15:47:57 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> In-reply-to: Your message of "Mon, 11 Jun 2018 15:15:18 +0200 ." <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> Date: Mon, 11 Jun 2018 15:47:56 +0200 Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 13:48:04 -0000 > The point is not to detect the NAT64, is to tell the CE "use it or > not". > > You may have a network with some customers that you want to use > 464XLAT, others only IPv6, others dual-stack. > > If we use a detection mechanism based in RFC7050 and RFC7225, the > CE must try both. Even more, if in the future there is another way > defined for the NAT64, the CE also need to try that. A CPE already has to have code for both RFC7050 and RFC7225 because it still has to find the translation prefix. Your DHCPv6 code point doesn't tell the CPE which protocol to use. Worse, you could send the prefix directly in DHCPv6 avoiding the need to run RFC7050 or RFC7225 in the first place. Note that there are multiple ways to have per customer DNS resolvers settings. One option is to vary the addresses of the DNS resolvers assigned to a particular link. Another is the use of ACLs in a DNS resolver to give different views to different devices. So the drawback of your proposal is that everybody (both CPE vendors and operators) has to implement the DHCPv6 option, only for the benefit of those operators that want to mix and match customers without resorting to other mechanisms. Personally I think that if you would make it mandatory for a CPE to issue a DHCPv6 request to find out about NAT64, then at least return the prefix as well. From nobody Mon Jun 11 07:05:44 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 5E38F130E53 for ; Mon, 11 Jun 2018 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsFP4Z1bBbbZ for ; Mon, 11 Jun 2018 07:05:40 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1259E130E51 for ; Mon, 11 Jun 2018 07:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528725938; x=1529330738; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=/pO4rU91 Mg41bAAj0B6VYyyHJQah8h/wWDYiTdmwieY=; b=Np3Entgdlxa1U1MZBVwLSkkI hPVVkujTN9P4V2PhEk1ivc3QMQbEDDeb1Uyd5fK61/NdJPqtQF9q0f8UxV6/qOz+ CxjJVTST0QEVSabCgBL6bjQO98k34MhiJajSSM/XFqjpr/rnHpmrCAAMty0AVlYn CuzYWH/TpNPgTq95zG4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Jun 2018 16:05:38 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 11 Jun 2018 16:05:37 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786119.msg for ; Mon, 11 Jun 2018 16:05:37 +0200 X-MDRemoteIP: 2001:470:1f09:495:3134:c630:857b:9b5 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 11 Jun 2018 16:05:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1700769604=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 11 Jun 2018 16:05:33 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 14:05:43 -0000 > The point is not to detect the NAT64, is to tell the CE "use it or > not". > > You may have a network with some customers that you want to use > 464XLAT, others only IPv6, others dual-stack. > > If we use a detection mechanism based in RFC7050 and RFC7225, the > CE must try both. Even more, if in the future there is another way > defined for the NAT64, the CE also need to try that. A CPE already has to have code for both RFC7050 and RFC7225 because it still has to find the translation prefix. Your DHCPv6 code point doesn't tell the CPE which protocol to use. Worse, you could send the prefix directly in DHCPv6 avoiding the need to run RFC7050 or RFC7225 in the first place. Yes, it tells the CE which ones are available. See section 1.4/1.5 of RFC8026. The operator code what transition mechanism (even several ones if available and in order of preference), in the S46 priority option. The CE then uses the first one that match with the list of transition mechanisms available in the CE. Note that there are multiple ways to have per customer DNS resolvers settings. One option is to vary the addresses of the DNS resolvers assigned to a particular link. Another is the use of ACLs in a DNS resolver to give different views to different devices. Right, but again, you're assuming that in addition to NAT64, DNS64 is being used, which is not necessarily the case for 464XLAT (in order to avoid breaking DNSSEC). You're also missing the point that the customer may have changed the DNS, so this doesn't work in that case. So the drawback of your proposal is that everybody (both CPE vendors and operators) has to implement the DHCPv6 option, only for the benefit of those operators that want to mix and match customers without resorting to other mechanisms. CE vendors will implement this anyway, if they want to follow this document and support other mechanism (not just for 464XLAT, but for the others). So actually, by making a single mechanism (RFC8026) to allow to sort out what are the transition mechanism to be used, it is much simpler. Operators only will need to use that parameter (not a new development, is only a parameter in the DHCP server config if it supports already RFC8026 for the other mechanisms). Personally I think that if you would make it mandatory for a CPE to issue a DHCPv6 request to find out about NAT64, then at least return the prefix as well. This was proposed, a few times in int-area, but people don't like "new" DHCP protocols, because they said that it can be done with RFC7050 or RFC7225. I don't agree with that (so I will agree with you and that was my contribution to https://datatracker.ietf.org/meeting/98/materials/slides-98-intarea-dhcpv6-options-for-discovery-nat64-prefixes-00), but anyway going back to that way and discussing for years, means meanwhile, we will need a more complex mechanism instead of defining a new option code for an existing protocol (RFC8026). This is something that is being done, I believe, from time to time in IETF documents. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Mon Jun 11 08:50:09 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 09C13130E4F for ; Mon, 11 Jun 2018 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf9E1NCKXaL9 for ; Mon, 11 Jun 2018 08:50:02 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79861277BB for ; Mon, 11 Jun 2018 08:50:01 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id r15-v6so15524358wmc.1 for ; Mon, 11 Jun 2018 08:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pLvnmmnS5iJPBOcdBdwfmEW70tmO2w6qdKSAlCuyV8Q=; b=cdFqFBy8+fNiLk+II+yNNO7BGZy1K4FU+7aHLDFkck4IxsAlmAWyRS1gdzDu2oMYm6 ZuSEduH/Cq/TEKUw9rouSTnpqMhdUAooP2v/nTf9pCUkP/+Ehl8tDt2/EihVY1ODAt7d G9Qx1IJcN/aIUHi1hVkcvkUYVWX7FqK911fx8RVzYdN9DXWOFlBlNFr8p3wgU1D9kMfc fcCBBes56sUduvxtTlU2CShOlc/XYq8YpbYmCTWWPVFklcl6UVcz/jL58DG3ZfFzBZBL +Mc53zttNPVmn07cBOd4zM35LoWVimppk83XoH/EXfSbjyBuuI5sz8v+1KTvLEQLWWP3 cTHQ== 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=pLvnmmnS5iJPBOcdBdwfmEW70tmO2w6qdKSAlCuyV8Q=; b=gtDi0YVi9a0UOQWtkaGfMqIyKcabqTLkD6jt01BAUziDriGtZGJDkneoGtzqMsDACr F02aWsgjqYYwimto3cXVBlQAd3jCX+emiFn99377B1ngoHXJR4ZKb3FpmdH8d69e27vS mGhvRqo18/zMiQYiHE/pUJdHELfApVHJRMJrq7MhOw3uDXgk7gtnBWso/F1WyXsJJij+ TnZmJO+eaqHeubuklzXjW1UYGDp2x9of6WNk84FKzyh+JrDQE+Wz/+ikjUZUBvbegk5+ vK/3BKeCUmbtg7XpkHOgoCs9AznmgUwQP9BBhloPQeODYYLJ+K9YvWZS1X5vGMp7whDi GRxw== X-Gm-Message-State: APt69E3wBWcTCc5pQ7t843uoNArUmhBsFg+TxXybr8IyqacRJom75mXR VM8kXn2F/6n+fFbnz8bxpu0= X-Google-Smtp-Source: ADUXVKJ2Zou+V+unkt0vJCfHt+uQzTsx6/vJiRdn3YQEdwxjhYgEBSrLNHaJ+NhVC1+CCzasn9q3Eg== X-Received: by 2002:aa7:d74f:: with SMTP id a15-v6mr19073679eds.109.1528732200439; Mon, 11 Jun 2018 08:50:00 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:f3a:accb:5c04:379e:d5cd? ([2601:647:4d01:f3a:accb:5c04:379e:d5cd]) by smtp.gmail.com with ESMTPSA id f2-v6sm18756619edq.28.2018.06.11.08.49.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 08:49:59 -0700 (PDT) From: Bob Hinden Message-Id: <8728F6C2-E3E8-4DD3-9AE9-E7B9CF8B98A8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_03E1C55E-9616-489C-B2AF-57627AB58906"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 11 Jun 2018 08:49:56 -0700 In-Reply-To: <647c7516-2167-57b6-8ef8-c903b988e082@gmail.com> Cc: Bob Hinden , IPv6 Operations , =?utf-8?Q?Vost=C5=99ez_Radek?= , Tomas Horacek To: Brian Carpenter References: <647c7516-2167-57b6-8ef8-c903b988e082@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] A new IPv6-over-foo implementation report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:50:09 -0000 --Apple-Mail=_03E1C55E-9616-489C-B2AF-57627AB58906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s always great in the IETF to see the running code of an RFC. Bob > On Jun 10, 2018, at 1:09 PM, Brian E Carpenter = wrote: >=20 > Hi, >=20 > Another important step in IPv6 deployment has occurred. >=20 > (The video is in Czech but the demo at the end is easy to understand.) >=20 > Forwarded with permission. >=20 > Brian >=20 > -------- Forwarded Message -------- > Subject: Re: RFC6214 > Date: Wed, 6 Jun 2018 15:34:27 +0000 > From: Tomas Horacek > To: Bob Hinden > CC: Brian Carpenter , Vost=C5=99ez Radek = >=20 >=20 > Hello Bob and Brian. >=20 >=20 > We did it, we have implemented your RFC6214 ! >=20 > Its 6.6. today, the day when IPv6 seminar takes place here in Prague: = https://www.cesnet.cz/akce/ipv6-2018/. We have presented our RFC6214 = implementation there with great success. >=20 > The info, video is not yet available in English (only in Czech, sry). >=20 >=20 > Video: https://www.youtube.com/watch?v=3DGTFXkXp_pig >=20 > WebPage: https://www.rfc6214.com/ -> = https://translate.google.com/translate?hl=3Den&sl=3Dauto&tl=3Den&u=3Dhttps= %3A%2F%2Frfc6214.com >=20 >=20 > Have a nice day :). >=20 > ________________________________ > From: Tomas Horacek > Sent: Wednesday, May 2, 2018 4:03 PM > To: Bob Hinden > Cc: Brian Carpenter > Subject: Re: RFC6214 >=20 >=20 >=20 > Thank you Bob for your quick reply. >=20 >=20 > We are aware of the publishing date :-). >=20 >=20 > S pozdravem / Best regards >=20 >=20 > Tom=C3=A1=C5=A1 Hor=C3=A1=C4=8Dek > [https://portal.totalservice.cz/AV_logo_all.jpg] >=20 > LAN/WAN security supervisor >=20 > M: +420 731 450 906 >=20 >=20 >=20 > thoracek@totalservice.cz >=20 >=20 >=20 > TOTAL SERVICE s.r.o. >=20 >=20 >=20 >=20 > U Uranie 954/18 >=20 > T: +420 270 002 811 >=20 >=20 > 170 00 Praha 7 Czech Republic >=20 > www.totalservice.cz >=20 >=20 > INFORMACE: Tato zpr=C3=A1va a p=C5=99ipojen=C3=A9 p=C5=99=C3=ADlohy = jsou ur=C4=8Deny v=C3=BDhradn=C4=9B v n=C3=AD uveden=C3=A9mu p=C5=99=C3=AD= jemci a mohou obsahovat d=C5=AFv=C4=9Brn=C3=A9, osobn=C3=AD nebo = chr=C3=A1n=C4=9Bn=C3=A9 informace. Pokud jste tuto zpr=C3=A1vu obdr=C5=BEe= li omylem nebo nedopat=C5=99en=C3=ADm, uv=C4=9Bdomte, pros=C3=ADm, = odes=C3=ADlatele a sma=C5=BEte tuto zpr=C3=A1vu. Tato zpr=C3=A1va nen=C3=AD= n=C3=A1vrhem na uzav=C5=99en=C3=AD smlouvy ani jeho p=C5=99ijet=C3=ADm, = leda=C5=BEe je tak v textu v=C3=BDslovn=C4=9B uvedeno. P=C5=99ijet=C3=AD = jak=C3=A9koliv nab=C3=ADdky nebo dokon=C4=8Den=C3=AD jedn=C3=A1n=C3=AD = je =C3=BA=C4=8Dinn=C3=A9 v=C3=BDhradn=C4=9B uzav=C5=99en=C3=ADm = p=C3=ADsemn=C3=A9 smlouvy podepsan=C3=A9 statut=C3=A1rn=C3=ADm org=C3=A1ne= m nebo jinou opr=C3=A1vn=C4=9Bnou =C4=8Di p=C3=ADsemn=C4=9B pov=C4=9B=C5=99= enou osobou. >=20 >=20 > ________________________________ > From: Bob Hinden > Sent: Wednesday, May 2, 2018 3:44 PM > To: Tomas Horacek > Cc: Bob Hinden; Brian Carpenter > Subject: Re: RFC6214 >=20 > Tomas, >=20 > I am not aware of any implementations. >=20 > Please look carefully at the date this RFC was published :-) >=20 > Bob >=20 >> On May 2, 2018, at 8:41 AM, Tomas Horacek = wrote: >>=20 >>=20 >> Hello there Robert, >> I am very sorry to interrupt you. >>=20 >> I just wanted to ask, is there yet real-life implementation of your = RFC6214 ? >>=20 >> If so, can you please share a link or a contact to the person/group = that implemented it ? >> If not, can you please give a advice, if any ? >>=20 >> Thank you for your time, patience, understanding. And thank you in = advance for your reply. >>=20 >> :-) >>=20 >> S pozdravem / Best regards >>=20 >> Tom=C3=A1=C5=A1 Hor=C3=A1=C4=8Dek >>=20 >>=20 >> LAN/WAN security supervisor >> M: +420 731 450 906 >> thoracek@totalservice.cz >>=20 >> TOTAL SERVICE s.r.o. >>=20 >> U Uranie 954/18 >> T: +420 270 002 811 >> 170 00 Praha 7 Czech Republic >> www.totalservice.cz >> INFORMACE: Tato zpr=C3=A1va a p=C5=99ipojen=C3=A9 p=C5=99=C3=ADlohy = jsou ur=C4=8Deny v=C3=BDhradn=C4=9B v n=C3=AD uveden=C3=A9mu p=C5=99=C3=AD= jemci a mohou obsahovat d=C5=AFv=C4=9Brn=C3=A9, osobn=C3=AD nebo = chr=C3=A1n=C4=9Bn=C3=A9 informace. Pokud jste tuto zpr=C3=A1vu obdr=C5=BEe= li omylem nebo nedopat=C5=99en=C3=ADm, uv=C4=9Bdomte, pros=C3=ADm, = odes=C3=ADlatele a sma=C5=BEte tuto zpr=C3=A1vu. Tato zpr=C3=A1va nen=C3=AD= n=C3=A1vrhem na uzav=C5=99en=C3=AD smlouvy ani jeho p=C5=99ijet=C3=ADm, = leda=C5=BEe je tak v textu v=C3=BDslovn=C4=9B uvedeno. P=C5=99ijet=C3=AD = jak=C3=A9koliv nab=C3=ADdky nebo dokon=C4=8Den=C3=AD jedn=C3=A1n=C3=AD = je =C3=BA=C4=8Dinn=C3=A9 v=C3=BDhradn=C4=9B uzav=C5=99en=C3=ADm = p=C3=ADsemn=C3=A9 smlouvy podepsan=C3=A9 statut=C3=A1rn=C3=ADm org=C3=A1ne= m nebo jinou opr=C3=A1vn=C4=9Bnou =C4=8Di p=C3=ADsemn=C4=9B pov=C4=9B=C5=99= enou osobou. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_03E1C55E-9616-489C-B2AF-57627AB58906 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsemiQACgkQrut0EXfn u6gxdQf/fAGPyHebsLaTjPUAPL0wZMjSN1jwjeAB3DI0Jsg3+TUG4KaSptF4OZZV q/aJPsb9TePvZD74OjxAOw062RHdKWa8f1tOZrHvxeqT1717K6sv5WBj26c64QMq lx/7bgsBfv3upZSAVk1Ku+iQkEYnV7uxfWJXsl4jBj0z4NXf5yfv66NbhmiL8MGv D0y3GczEM5VdiwuMH/leeewRKtujKNWA06g6IsinyVu0ZMlsHbVdonhVbBL2K+5a pnigZs8wvAh3BC0HrA3ysJI/RXtgsS6U4oiKhaFxACgW95L3lVzld7cDAHWKwzfM KmZ2p1zLOdltBbPm7M28qk3YWifP+A== =mvQ6 -----END PGP SIGNATURE----- --Apple-Mail=_03E1C55E-9616-489C-B2AF-57627AB58906-- From nobody Mon Jun 11 09:37: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 CE717131059 for ; Mon, 11 Jun 2018 09:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RHVITtf7uur for ; Mon, 11 Jun 2018 09:37:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F0613102D for ; Mon, 11 Jun 2018 09:37:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fSPoO-0000FqC; Mon, 11 Jun 2018 18:36:56 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> In-reply-to: Your message of "Mon, 11 Jun 2018 16:05:33 +0200 ." <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> Date: Mon, 11 Jun 2018 18:36:56 +0200 Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:37:13 -0000 >Right, but again, you're assuming that in addition to NAT64, DNS64 is being us >ed, which is not necessarily the case for 464XLAT (in order to avoid breaking >DNSSEC). You're also missing the point that the customer may have changed the >DNS, so this doesn't work in that case. Thinking about this a bit more, not so much DNSSEC, but how DNS64 can break things. It is safe to assume that DNS64 will be used only in combination with NAT64. I.e., if an operator wants to provide a CPE with dual stack or any other transition mechanism, there won't be DNS64. This means that if a CPE finds DNS64, then it can safely assume that there is NAT64. No need for a DHCP option. I guess that if a CPE requests a PCP Server Option using DHCPv6, then it would also make sense to request the S46 Priority Option as well. But only in that case. From nobody Mon Jun 11 09:59: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 13BA3131036; Mon, 11 Jun 2018 09:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3CkAck5wALlQ; Mon, 11 Jun 2018 09:59:13 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B499513107E; Mon, 11 Jun 2018 09:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w5BGxB2C029133; Mon, 11 Jun 2018 09:59:11 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w5BGx8fc028970 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 11 Jun 2018 09:59:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 11 Jun 2018 09:59:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Mon, 11 Jun 2018 09:59:07 -0700 From: "Templin (US), Fred L" To: V6ops Chairs , "v6ops@ietf.org list" Thread-Topic: [v6ops] IETF 102 Agenda Thread-Index: AQHT/40dm7H3mQ/Oa0qSxuSjbjYCZaRbSonA Date: Mon, 11 Jun 2018 16:59:07 +0000 Message-ID: <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> In-Reply-To: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:59:24 -0000 Hi Fred, 'draft-templin-v6ops-pdhost' has been updated, and received list traffic bo= th before and after the update was posted. Please add to the agenda. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Friday, June 08, 2018 5:59 PM > To: v6ops@ietf.org list > Subject: [v6ops] IETF 102 Agenda >=20 > Permit me to comment on the IETF 102 agenda as it appears to be shaping u= p. >=20 > We have > - an invited talk by George Michaelson of APNIC, who has been looking at= IPv6 traffic in world economies > (You might find the observations surprising; hint, guess which economy= has the most IPv6 traffic? Which markets?) > - draft-ietf-v6ops-transition-ipv4aas > - draft-ietf-v6ops-ipv6rtr-reqs >=20 > draft-ietf-v6ops-conditional-ras is under discussion in the IESG, and is = waiting for draft-ietf-rtgwg-enterprise-pa-multihoming before > proceeding. We have several other individual contributions, and have disc= ussed most of them on the list since IETF 101. The chairs > don't see a supporting interest level in them at this time. >=20 > We have two slots, two hours each, at IETF 102. The chairs are right now = contemplating using one a slot for those three topics and > perhaps a set of lightning talks, and letting the second slot go. >=20 > To change that, we need to see new drafts (e.g., new content) and support= ing list traffic. >=20 > Your turn... From nobody Mon Jun 11 10:15: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 585AD130E40 for ; Mon, 11 Jun 2018 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmoyEkO459OT for ; Mon, 11 Jun 2018 10:15:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B83130E3A for ; Mon, 11 Jun 2018 10:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528737323; x=1529342123; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=G1EnpNX0 snc8NPPsJf6cazsHN2z/d0l+lkH/7ODXgd8=; b=q6ukdPk3Goeu6mvodUeQ8n9h TQuz2tcPJ/lVnciscMG+mX+JrGyrEVgisZL1+M3JPhHpLjrqx/gh5j68RS0LeJk1 0jfNZwPVggqh3pQtgVvKJEmC0LpgLKffLLwH8hYHqLzRwaKOKIIvumRL72k7SIgp FbGNer0/aFIOg4Fm3t0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Jun 2018 19:15:23 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 11 Jun 2018 19:15:23 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786260.msg for ; Mon, 11 Jun 2018 19:15:23 +0200 X-MDRemoteIP: 2001:470:1f09:495:3134:c630:857b:9b5 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 11 Jun 2018 19:15:23 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1700769604=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 11 Jun 2018 19:15:21 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 17:15:29 -0000 I see your point, but what an operator need is a "100% sure" way to make su= re that they can tell the CPE to not use a specific transition mechanism (w= hich for the other mechanisms we have with RFC8026). So, assuming that DNS64 is only there if combined with NAT64 is not "safe 1= 00%" because if using CLAT, you can avoid having a DNS64 (this is the one t= hat breaks DNSSEC, in case I wrote it incorrectly before). But if the user changed the DNS in the CPE (which is quite common), there w= ill not be DNS64 and still may be the ISP want to have the CLAT running, be= cause is using that for the IPv4 service for that particular customer. If you agree that the CPE may request a PCP option, etc., then request the = S46, I think you are in agreement that we need the S46 priority option code= s for all the mechanism that we are asking to be supported by the CPE, righ= t? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: en nombre de Philip Homburg Fecha: lunes, 11 de junio de 2018, 18:37 Para: CC: JORDI PALET MARTINEZ Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas=20 >Right, but again, you're assuming that in addition to NAT64, DNS64 is = being us >ed, which is not necessarily the case for 464XLAT (in order to avoid b= reaking=20 >DNSSEC). You're also missing the point that the customer may have chan= ged the=20 >DNS, so this doesn't work in that case. =20 Thinking about this a bit more, not so much DNSSEC, but how DNS64 can b= reak things. =20 It is safe to assume that DNS64 will be used only in combination with N= AT64. I.e., if an operator wants to provide a CPE with dual stack or any othe= r transition mechanism, there won't be DNS64. =20 This means that if a CPE finds DNS64, then it can safely assume that th= ere is NAT64. No need for a DHCP option. =20 I guess that if a CPE requests a PCP Server Option using DHCPv6, then i= t would also make sense to request the S46 Priority Option as well. But o= nly in that case. =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 11 11:46:44 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 64561130E9B for ; Mon, 11 Jun 2018 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-R8wvC2jePJ for ; Mon, 11 Jun 2018 11:46:39 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25B5130EAE for ; Mon, 11 Jun 2018 11:46:38 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id e16-v6so16383610wmd.0 for ; Mon, 11 Jun 2018 11:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DXTl3FTY9+My/qmBI5UWhqHBv4xIeNS74bq5pmjSAV8=; b=NUzcii7iO0T+5GdpgA3iGIlZ/l1kP9iI1fhLorBdb5I6mXOirD+EzZX2LfE7MzrO12 Pfx+glz7szriEbeZ/iBGG2tCSAZIsXqhG4/NlQ0Wn7RoQrGt+YDmCTJ75bjWx74UiwWt +dMCnn2bqb4XwS9NJ6FRN4zULhs9u4mX199RWFXSIVumU+cl2ZfaM/NaicQ0/Y6Fj8ZR nsP5CjeluTQvsW+xCMPhA0rQyl/czey4XaKwfqImT3G1lAGe7gfYsSphab7a+VaPPdCt GHMbxe2TRsETDguQude2rKwbanoIT7qWadoF10e1s2aC7Vn5HJT4eg+YW3Up6MYHhpzC riQw== 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=DXTl3FTY9+My/qmBI5UWhqHBv4xIeNS74bq5pmjSAV8=; b=F6ZGt3DIGHsihkUvGXV1mEt3CA/JxP0nEzfyDUlCxzwqP6AeKhpL8ad5/PZ/4EDIKl c/EmhAXZI3YgMX4T7lfaJ+oMT2WepR4Tnj0uuh3LEVkn8twnHz6FjA4V+A3gXfFHOHcM SNsNcxaviKz0q/hkJ9pPSpE+JQCq0D7hVv+qUrSBZ8rP5t90IGp2MbMVuWEoII63fURS XZn5Do4clZBrfT3dyxJP2wg8PArLSYMElcrVuBJrJg15Ikz9cG+perKMHe6aEubK8a3j DYViqGhva8ACiyKCga7bVDTlGQpkYfdjBS7bGPRRlZfiFNM4N51LGaSqbIlPlSJtX2rD GqZQ== X-Gm-Message-State: APt69E2rbRpPOjreM+TxbkeJcjfSOz2f47ytoMkiklsBh1KfyVMb3MhT tRPamKEJYhfeeJqE8YgwcVY= X-Google-Smtp-Source: ADUXVKIvcrm+KJ6B8/tyYUsqGUEc1K9gLRlAl+rH31csXSTBTwLDGECMLvd6DtH+E679ZgzbeGCPvQ== X-Received: by 2002:a50:892f:: with SMTP id e44-v6mr302854ede.213.1528742797341; Mon, 11 Jun 2018 11:46:37 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::11bf? ([2600:8802:5600:1546::11bf]) by smtp.gmail.com with ESMTPSA id b58-v6sm26850971edb.59.2018.06.11.11.46.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 11:46:35 -0700 (PDT) From: Fred Baker Message-Id: <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_28BD3DF5-4447-4F3F-9D0D-B0016C2EEFC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 11 Jun 2018 11:46:32 -0700 In-Reply-To: <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> Cc: "v6ops@ietf.org list" To: Fred Templin References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 18:46:42 -0000 --Apple-Mail=_28BD3DF5-4447-4F3F-9D0D-B0016C2EEFC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L = wrote: > Hi Fred, >=20 > 'draft-templin-v6ops-pdhost' has been updated, and received list = traffic both > before and after the update was posted. Please add to the agenda. >=20 > Thanks - Fred Hi. I'm looking at the discussion post-IETF-101, and looking for someone = saying "I support this draft. I think it describes something I want to = deploy in my network." This is an operational working group; I'm looking = especially for comments from network operators. This is a discussion you = and I have had a number of times. What the chairs want to give agenda = time to is drafts that the working group participants find useful and = interesting. We gauge that from list discussion. So it's not "number of = comments, when comments are specifically solicited, exceed zero", but = "someone said it was useful and interesting in their deployment". Since IETF 101, we have had two threads on the subject of pdhost. I = initiated "let's discuss this" in late April: = https://www.ietf.org/mail-archive/web/v6ops/current/msg29222.html. In that thread, we had comments from - Dusan Medric, who wondered whether there was a discussion of = allocating a prefix (such as a /64) to a host, - Joe Touch, Mark Smith, and Ole Troan regarding the distinction a = "weak" and a "strong" host and between a "platform", a "router", a = "host", and a "node", and - Alexandre Petrescu, on the utility in his IOT MIPv6 network. I initiated another after your update on 29 May = (https://www.ietf.org/mail-archive/web/v6ops/current/msg29275.html). In = that, you and Alexandre Petrescu discussed the utility of this in his = IOT environment, in which he wanted to use RFC 3633 to delegate a prefix = to an IOT router for use in an enclave in his network. You and he = disagreed on what was to be done with the delegated prefix. I'm still looking for a comment from a working group participant saying = s/he finds draft-templin-v6ops-pdhost, in its 21st revision, "useful and = interesting". What I see is 14 emails since IETF 101, many of which you = responded to, from people who fundamentally disagreed with you on one = point or another. General comment to those on the CC line: if this draft describes = something useful to you in your network, your comment can dramatically = change the conversation between Fred and myself. --Apple-Mail=_28BD3DF5-4447-4F3F-9D0D-B0016C2EEFC7 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+AFAlsew4gACgkQEhdRnd2G P+BCzhAAjosTr84cTPYWeA1u7TxcgoqxA6bUxKKO8epphIemmLekeCA5Jlm9bMTN hSnFkYPtlaNKuEiGf34zx4ITboBPaoLWFhec04IfU+Qw9dNDaJxni6xhKvHaK89h 9RvpXram6Wg6NzPHUcLwMOfXQEzK6FjmMaHAtvGW4WNSXJelpGb8V5y/kj8nTcnI P/VSKjD3LaUsSxW+JtLpQ0tU7uwu4YNXm4cs72IHRvgKyu1FS4PVYk/6Q/tNE46o 99JVHFXfFtP2PJPKhjSbiNnEZlGAMuQJOV2q3/8rOzKcl/edTJQhSSAgfvsvACay 9IGJjyYT9rDRlJTSCUlDDM2rG50kuCgX7Yo+Lx02rumbeXcbiVMaJG+fCnjXH/3x +OmuF5SMapfm1w5PVMpUMkkIEXEGJqUl9kG6Le1EIZKzTsW+oCmtIvlk0jvHeWNJ d8IH1YAhZRoFMoH0onY5kFHKtg0qV14gnv0irub7yZfHJ54l1RktcRnlXTvKOJzG NJpHhjYMgUe4L/wMn2ZC/Xc2OQXvV6KIDjO3uGNTcKacYVxBL5PJdWiKio2y1H7n kPBrdMCvUFHVznOv9gwja5Fu+IBWidbIFmXvEAaQiObZKeZ8egock95cs67ztE4n T02TxCnNdVedrqBdfS9Bm5qGgxVeFNpVzlyw7Paw3WCPQYrTvrM= =AObH -----END PGP SIGNATURE----- --Apple-Mail=_28BD3DF5-4447-4F3F-9D0D-B0016C2EEFC7-- From nobody Mon Jun 11 12:14: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 20484130EAE for ; Mon, 11 Jun 2018 12:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtAXuX8HoiKU for ; Mon, 11 Jun 2018 12:14:47 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707CF130E7D for ; Mon, 11 Jun 2018 12:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528744484; x=1529349284; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=fUNuB2Mp 66SG4Lyyel+gmwD565d2IOUY7YngvSSyP+4=; b=GI3SS0R9WmQN1B6LTKG3w6wz Fg/+pwkXmR3FX4Ptu2pmOmxKAyM2wRvRAiYV21JgSHzcQyAxa02L2gu97aZOpZaI Ga/ZBDGLH/1CYtGVRbOhl43/BVfuCdmhfyXDsGp+4MO/xasubztCAMJtmKT1DxxQ 7uMEeu88GpiKI0neOmg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 11 Jun 2018 21:14:44 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 11 Jun 2018 21:14:44 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786320.msg for ; Mon, 11 Jun 2018 21:14:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:3134:c630:857b:9b5 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 11 Jun 2018 21:14:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1700769604=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 11 Jun 2018 21:14:42 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <69A3AE07-3AEA-423E-B8A7-F7A8512A84DB@consulintel.es> Thread-Topic: [v6ops] IETF 102 Agenda References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> In-Reply-To: <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:14:51 -0000 I'm sure in March I confirmed that I will like to see this work as WG item,= but can't find my email ... Anyway, I just read the last version, and again, I confirm that I believe i= t is useful and will like to see this work to progress as WG item. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: lunes, 11 de junio de 2018, 20:47 Para: Fred Templin CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] IETF 102 Agenda On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L wrote: > Hi Fred, >=20 > 'draft-templin-v6ops-pdhost' has been updated, and received list traf= fic both > before and after the update was posted. Please add to the agenda. >=20 > Thanks - Fred =20 Hi. I'm looking at the discussion post-IETF-101, and looking for someon= e saying "I support this draft. I think it describes something I want to de= ploy in my network." This is an operational working group; I'm looking espe= cially for comments from network operators. This is a discussion you and I = have had a number of times. What the chairs want to give agenda time to is = drafts that the working group participants find useful and interesting. We = gauge that from list discussion. So it's not "number of comments, when comm= ents are specifically solicited, exceed zero", but "someone said it was use= ful and interesting in their deployment". =20 Since IETF 101, we have had two threads on the subject of pdhost. I ini= tiated "let's discuss this" in late April: https://www.ietf.org/mail-archiv= e/web/v6ops/current/msg29222.html. =20 In that thread, we had comments from - Dusan Medric, who wondered whether there was a discussion of alloca= ting a prefix (such as a /64) to a host, - Joe Touch, Mark Smith, and Ole Troan regarding the distinction a "w= eak" and a "strong" host and between a "platform", a "router", a "host", an= d a "node", and - Alexandre Petrescu, on the utility in his IOT MIPv6 network. =20 I initiated another after your update on 29 May (https://www.ietf.org/m= ail-archive/web/v6ops/current/msg29275.html). In that, you and Alexandre Pe= trescu discussed the utility of this in his IOT environment, in which he wa= nted to use RFC 3633 to delegate a prefix to an IOT router for use in an en= clave in his network. You and he disagreed on what was to be done with the = delegated prefix. =20 I'm still looking for a comment from a working group participant saying= s/he finds draft-templin-v6ops-pdhost, in its 21st revision, "useful and i= nteresting". What I see is 14 emails since IETF 101, many of which you resp= onded to, from people who fundamentally disagreed with you on one point or = another. =20 General comment to those on the CC line: if this draft describes someth= ing useful to you in your network, your comment can dramatically change the= conversation between Fred and myself. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 11 12:48: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 9C1A8130EC3 for ; Mon, 11 Jun 2018 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5CWfu4Nk5lN for ; Mon, 11 Jun 2018 12:48:21 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ECD130EC8 for ; Mon, 11 Jun 2018 12:48:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w5BJmK2F037592; Mon, 11 Jun 2018 12:48:20 -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 w5BJmHYO037552 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 11 Jun 2018 12:48:17 -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.1367.3; Mon, 11 Jun 2018 12:48:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Mon, 11 Jun 2018 12:48:16 -0700 From: "Templin (US), Fred L" To: Fred Baker CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] IETF 102 Agenda Thread-Index: AQHT/40dm7H3mQ/Oa0qSxuSjbjYCZaRbSonAgACUvQD//5oyYA== Date: Mon, 11 Jun 2018 19:48:16 +0000 Message-ID: <727eaf16c964422da8b2ffbf2bf8c6c0@XCH15-06-08.nw.nos.boeing.com> References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> In-Reply-To: <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:48:25 -0000 Hi Fred, There was a similar question back in the March 2018 timeframe, and there we= re several responses in support. The document was then presented remotely at IETF101, but there was no time left over for questions afterwards. I am planning to attend IETF102 in person, so would be better able to inter= act and get a sense of the room. Thanks - Fred > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Monday, June 11, 2018 11:47 AM > To: Templin (US), Fred L > Cc: v6ops@ietf.org list > Subject: Re: [v6ops] IETF 102 Agenda >=20 > On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L wrote: > > Hi Fred, > > > > 'draft-templin-v6ops-pdhost' has been updated, and received list traffi= c both > > before and after the update was posted. Please add to the agenda. > > > > Thanks - Fred >=20 > Hi. I'm looking at the discussion post-IETF-101, and looking for someone = saying "I support this draft. I think it describes something I > want to deploy in my network." This is an operational working group; I'm = looking especially for comments from network operators. > This is a discussion you and I have had a number of times. What the chair= s want to give agenda time to is drafts that the working group > participants find useful and interesting. We gauge that from list discuss= ion. So it's not "number of comments, when comments are > specifically solicited, exceed zero", but "someone said it was useful and= interesting in their deployment". >=20 > Since IETF 101, we have had two threads on the subject of pdhost. I initi= ated "let's discuss this" in late April: > https://www.ietf.org/mail-archive/web/v6ops/current/msg29222.html. >=20 > In that thread, we had comments from > - Dusan Medric, who wondered whether there was a discussion of allocati= ng a prefix (such as a /64) to a host, > - Joe Touch, Mark Smith, and Ole Troan regarding the distinction a "wea= k" and a "strong" host and between a "platform", a "router", > a "host", and a "node", and > - Alexandre Petrescu, on the utility in his IOT MIPv6 network. >=20 > I initiated another after your update on 29 May (https://www.ietf.org/mai= l-archive/web/v6ops/current/msg29275.html). In that, you > and Alexandre Petrescu discussed the utility of this in his IOT environme= nt, in which he wanted to use RFC 3633 to delegate a prefix to > an IOT router for use in an enclave in his network. You and he disagreed = on what was to be done with the delegated prefix. >=20 > I'm still looking for a comment from a working group participant saying s= /he finds draft-templin-v6ops-pdhost, in its 21st revision, > "useful and interesting". What I see is 14 emails since IETF 101, many of= which you responded to, from people who fundamentally > disagreed with you on one point or another. >=20 > General comment to those on the CC line: if this draft describes somethin= g useful to you in your network, your comment can > dramatically change the conversation between Fred and myself. From Simon.Allard@vocusgroup.co.nz Mon Jun 11 14:45: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 3F4E0130DBE; Mon, 11 Jun 2018 14:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=t3inz.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 CJpoUwQWcH3q; Mon, 11 Jun 2018 14:45:37 -0700 (PDT) Received: from AUS01-ME1-obe.outbound.protection.outlook.com (mail-me1aus01on0112.outbound.protection.outlook.com [104.47.116.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57680130ED4; Mon, 11 Jun 2018 14:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=t3inz.onmicrosoft.com; s=selector1-Vocusgroup-co-nz; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a9Dc5Y5IJF1Tv4pZTAwS1w0GQH0k02axwFHuHAdhCR8=; b=PgR4YhneHwCAN6h42o2lpRAiyFAmnzH4FExDo6L9y5b8o4EuOBHtfAK+weEXuIh6B+PkHd7JjQD8Rf8okstvLk3XxrobexQ7LYe0fCWJ2LXsf+wmClvbQ0w4apRuWyz8kiVOmcciAsOOL7Vhwo6TG5pg+seOewJiBZQ0z0/GtNg= Received: from SY3PR01CA0127.ausprd01.prod.outlook.com (2603:10c6:0:1b::12) by SY3PR01MB1273.ausprd01.prod.outlook.com (2603:10c6:0:13::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Mon, 11 Jun 2018 21:45:19 +0000 Received: from ME1AUS01FT012.eop-AUS01.prod.protection.outlook.com (2a01:111:f400:7eb4::206) by SY3PR01CA0127.outlook.office365.com (2603:10c6:0:1b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.841.13 via Frontend Transport; Mon, 11 Jun 2018 21:45:19 +0000 Authentication-Results: spf=pass (sender IP is 104.210.80.79) smtp.mailfrom=vocusgroup.co.nz; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=vocusgroup.co.nz; Received-SPF: Pass (protection.outlook.com: domain of vocusgroup.co.nz designates 104.210.80.79 as permitted sender) receiver=protection.outlook.com; client-ip=104.210.80.79; helo=au1.smtp.exclaimer.net; Received: from au1.smtp.exclaimer.net (104.210.80.79) by ME1AUS01FT012.mail.protection.outlook.com (10.152.232.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.863.11 via Frontend Transport; Mon, 11 Jun 2018 21:45:17 +0000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (65.55.88.178) by au1.smtp.exclaimer.net (104.210.80.79) with Exclaimer Signature Manager ESMTP Proxy au1.smtp.exclaimer.net; Mon, 11 Jun 2018 21:45:18 +0000 X-ExclaimerHostedSignatures-MessageProcessed: true X-ExclaimerProxyLatency: 14844018 X-ExclaimerImprintLatency: 2968825 X-ExclaimerImprintAction: 375dd18188ed4595ac9b28cba8eb8cd4 Content-Type: multipart/related; boundary="----_=_NextPart_c07ed87f-3415-4257-a3a1-89f4081b9f11" Received: from ME2PR01MB2227.ausprd01.prod.outlook.com (52.134.203.16) by ME2PR01MB2916.ausprd01.prod.outlook.com (52.134.209.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.15; Mon, 11 Jun 2018 21:45:15 +0000 Received: from ME2PR01MB2227.ausprd01.prod.outlook.com ([fe80::15fa:7b86:b13a:2b67]) by ME2PR01MB2227.ausprd01.prod.outlook.com ([fe80::15fa:7b86:b13a:2b67%2]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 21:45:15 +0000 From: Simon Allard To: "v6ops@ietf.org" , "fredbaker.ietf@gmail.com" CC: "intarea-chairs@ietf.org" Thread-Topic: [v6ops] draft-patterson-intarea-ipoe-health Thread-Index: AQHUAcqQY6lm0msC8UaiT0txXGlSj6Rbky3Q Date: Mon, 11 Jun 2018 21:45:15 +0000 Message-ID: References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> In-Reply-To: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Simon.Allard@vocusgroup.co.nz; x-originating-ip: [2404:4408:11::18] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; ME2PR01MB2916; 7:Q6tX2YcDPNyI84fOVty8jAjld2B3ML7zVqcD3WGr4T85yky762F0ketY8vUg1aPIE7I/7nfkgSZ69GfSlA5m883y0JxbkPczSUuOKLbAjR2KQ9CitJzgUSyEyCpyD4oF6wd0+nWLhZCqsPeH6M2HbJ+3kcSH/VEgKl+M69CHJ5zeuKglDLwh7cGdx1raRvMPxp3WeI2lXN+iQkTCn6RkdeqKBuAiIfkkF+IB6fj2u9J+3yoYYsJwH+8YGxG0Iuy7 x-ms-exchange-antispam-srfa-diagnostics: SOS; X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:ME2PR01MB2916; X-MS-TrafficTypeDiagnostic: ME2PR01MB2916:|SY3PR01MB1273: X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-test: UriScan:(209352067349851)(85827821059158); UriScan:(209352067349851)(85827821059158); X-MS-Exchange-SenderADCheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:ME2PR01MB2916; BCL:0; PCL:0; RULEID:; SRVR:ME2PR01MB2916; BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:SY3PR01MB1273; BCL:0; PCL:0; RULEID:; SRVR:SY3PR01MB1273; x-forefront-prvs: 070092A9D3 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(366004)(39380400002)(346002)(189003)(199004)(22974007)(68736007)(2501003)(8676002)(33656002)(305945005)(74316002)(59450400001)(72206003)(966005)(7696005)(74482002)(7736002)(81166006)(76176011)(8936002)(2900100001)(5250100002)(14454004)(99286004)(46003)(81156014)(5003630100001)(186003)(6436002)(2906002)(55016002)(106356001)(25786009)(316002)(229853002)(97736004)(3280700002)(3660700001)(6306002)(6246003)(102836004)(446003)(478600001)(6506007)(86362001)(9686003)(53936002)(53546011)(486006)(5660300001)(110136005)(105586002)(4326008)(11346002)(6116002)(39060400002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:ME2PR01MB2916; H:ME2PR01MB2227.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: vocusgroup.co.nz does not designate permitted sender hosts) X-Microsoft-Antispam-Message-Info-Original: 7H5gubZLR2EQ9uW/JYpKSb6CT4YvnCi4pmzD8vYkRkcfW9QuuLczho/2F5G9zTBQKgu/nv5cNvsjSj0984qm+CnMnSpo5CGcn5Taj1p6QnYK4VYhswxo2I8/WGF09ijRrbCtIeT9iWKXFhtpjpi85ZNyLhMlo5lroS6S6cQoTsUrKllZO9Zx/9s5X0U+dffz SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 170a0e99-b347-4aca-c867-08d5cfe49fea X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2916 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: ME1AUS01FT012.eop-AUS01.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:104.210.80.79; IPV:CAL; SCL:-1; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(346002)(376002)(2980300002)(438002)(199004)(189003)(22974007)(126002)(6116002)(26005)(11346002)(74482002)(9686003)(54556002)(236005)(446003)(316002)(476003)(6246003)(33656002)(14454004)(486006)(2906002)(336012)(102836004)(53386004)(186003)(2690700001)(25786009)(39060400002)(356003)(84326002)(2900100001)(106466001)(606006)(6306002)(966005)(5003630100001)(55016002)(72206003)(733005)(8936002)(246002)(53546011)(8676002)(26826003)(5660300001)(2501003)(7696005)(575784001)(229853002)(86362001)(6506007)(59450400001)(16586007)(74316002)(478600001)(76176011)(33964004)(110136005)(7596002)(7736002)(4326008)(99286004)(7636002)(106002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SY3PR01MB1273; H:au1.smtp.exclaimer.net; FPR:; SPF:Pass; LANG:en; PTR:au1.smtp.exclaimer.net; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; ME1AUS01FT012; 1:BmcN6MZHm9ywqhpxqLnTVLnNjvjoNcI6+0BEz7cPvtlaT80tqy3zsl+BbOG3a0AMI/lmPQYqr1gSZHDETdQlFv3QC3zoYS00Cbks5GDHbg7dD8zNAvDjEtMX0l0Ii7FI X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4608076)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:SY3PR01MB1273; X-Microsoft-Exchange-Diagnostics: 1; SY3PR01MB1273; 3:F/qL1UNHA74Iiv7sJ24V2wzNzvDgydwhx1BalnVttngKY6HR8ryu7DheuVGwItQuvbRqGgZTEkaiGhjek5f6QwcwMLm3pb4wBVmU5wRMQ5eTkYK/rZB02NJdxDigLtmQDROp7XPNLeoLjbz6u1vueqRf5QxrZrHaB/RAfrkK5UvynpJli6nneuj45A4Q+EzrYLhlrG9E7MfvegZd81/iWVuc8T9EfV1RlF3Rlx2NFG4+3IkMvaJ/VlD4gl1ZyZwOAMJDqfhm2puyrenW3h66pocmazNANH8Kou8kOOJXgVsGUEZzVHAgp/MxfMcvF5A8WDyzmqi0aZPCyqKtLRCySQ==; 25:MHfFz5GNFGxMc8ZW6UVxoZzQkwUWVZTfUfl4btiGiYG0fBpDkb3h0N3N7gNx3Xl3MJsFdeuZXhYWgj4fbYJr92S4n8CTFDQRwSs50zklW/qSjRg81FD2E04rRSaSDlFKjZzKHc6C8zqrQhouYcVLPOgG45Ml8W46JXfnUuG42whrLWqW5NGnyau6PL1BbqI+mlRPx4g3wRZQdCWKZ8bHGkaTP72amC3SDhO6Pa7A7SSm+0NucQeUJlxRbGQdbK/0+6oUsh2jQiJeMljVdBsr40shrbRhNnoPlKHWSfcsB6u02g+U3+JuzVffeRqI/D4BQsjmtf3XvHfutauKwjwwgg==; 31:WIUvofkgS7yW/0lKVB7TuGnw1htfhlAjlDLTpWFQuuqGZvP1OwelB+9lPiSmWEfyuR8bLXyW0x3H00WMiPB6oMBHvlX2CjNVgPA3JXHR2+U8xfOtRg9RnNdiM6ROIRDumdPxDL/Taz6Qk9zxRuH1TlBGJDqYMu8zE9504pxbf/ARjhpFw3J58p1ZZB1PpcbVpxaHyFY7xtzwCG2bTSFADHeKGybWAMh05lsuEsOXZNc= X-Microsoft-Exchange-Diagnostics: 1; SY3PR01MB1273; 20:phrI1Z6uWCqBQNMkwNymzyjnE//8ipjTo/5PX82oEfrzJypgwY9Ixd7IirpqIdxdzOC9KphOJTNrE8i+KrBLLNEq0P18eB7gIplTuVNFr9DWhhOCpbtStiO0T1soU0+ErysmGGg2Tb0Z7NgMrof0M3fBNyCNq5VxmCP+ArpZ9tXlXszkNsagySq1dHgSkFak9AGciZNW4jA5FxDc4v++HaFfdnkAZUFjm3b8Z/YVhwBDTXAOMY79MCe/enEOaD/SkRYp5NfrB++YvPTeVsqv+QeVwuzUIjk2Q5V48dtF78Mlv2efeOZw1NmuWWSXq2NjpeTGcqAynAbEn7uwWO0nfTT03rLCGWDgGGE5iY8M0V8QzV+T7z5LQmm6CJ3uZDbDDVOMr/nXogzpaAWxAWgI63/px/STErmd/TVSbUrRAb49AbRhYeWcZwPurE6j4n8mKZTnm2PRd9GSEA5grx6EsalFCMjrCYISKOugz7Srzvee/nCgCNT1L03tMzztFMbu; 4:MIaaep/qmlBWgBPy76SWoslbdOWUcxA7xagUc7x8jEaB9oVs09GUxuoUPMNUR3v7MpNgcTd9WqAETCgAtXL3YHlC66rN4jlkN1WfIl8XEEm5WaFPUme/RqRuAzZ5dDY6RU6EMRCVTtG/GNP1Xnq/pHkaEqJSCrbcKKCo3DF1oa43HggQxwE+gokltFOSUAvN3kgOZGCEGSs9OqtRLVrKd3ydiQ2+Myg4CasiC+3qiy+5BDtkV3m6Fmx1e2TCtpIMGuSvoOJ/7wz3ZPBJqCDp4djc9xvrABSXiJfT7ztlfImxL0UQlK3NNOMfdxo3csOyWNm1OU5fctMdnKzIu+GieQis66Xw2i3oyEi46/etbrM= X-Forefront-PRVS: 070092A9D3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SY3PR01MB1273; 23:BJJSy66fnPeMKO6DBunv4hPT/EKb0KFRbJ2ribigZ?= =?us-ascii?Q?cBP/P/1P1WkLh2XrQV4Okpy5Yr60jN6yak1s2xu3IGJB2RqYe4NBeM3Gqqgb?= =?us-ascii?Q?u46sArLxMT/lJbq5HLKG5lfQbSi9Zrx1x+bNjdea8IqUzNMVcCSMlaQKTml9?= =?us-ascii?Q?IyNYyvzL4LhoqHZHw+Fqz0wppNvchNAVL+XK53gQSLjdx7xFHgSkUyUVD6iU?= =?us-ascii?Q?JVFZr+VRJi8iOLLQas8te8l1me556qt6oCPinn2znl/jrYrDgGHubnBTYc03?= =?us-ascii?Q?MnE6HX3g6a1slytolTSRBxiFSxoTrwHAYjsZxUY8kehUDbYA81pkUiwEI6u6?= =?us-ascii?Q?u9edsPSyCsqvQtLpQM1xwrEyBUc4H2yRkqSEkm4mBqk/ntA8ODKuZuy8SwN1?= =?us-ascii?Q?RK9QCQ6YlUdVb+1H238ZRY6/YLCailkFda7RkZ3LOqmClSJDtoxzOWd+giZq?= =?us-ascii?Q?CrgZ+cpD7924/cQXkqWFUOfdtyn7G3SQ6H1RTlu08+U85ZMx2Yady6T6rOoU?= =?us-ascii?Q?qJzK7W+ZlBoV9lOyoe2Q8UyB2GqM7BQPDc+HK6zDASHedkVI/1KdRZIl1JUJ?= =?us-ascii?Q?FWhb8Ehg9OPu8BFAOIKVJQrqmSZ78jOhxrQjpYvSypojA9oWcwy9eToKzLxQ?= =?us-ascii?Q?GCx0hg9UF/hhBQ4stjnf9LSs187zh8n49cYd5/neVj8jy1ipclE/7B8PlLbp?= =?us-ascii?Q?sRK0uRS9fxOBCSfc7FTrOt1cSM9Op5HB9rS+hMpjXz3BJwofmsRcHWXxHAGs?= =?us-ascii?Q?eghRsdhbeJw0NpoqhartS0kKJPc/pxDvQg95CVvqnkZN8DN9kUEvi+8iclUZ?= =?us-ascii?Q?8akCMIOH6P6v/VcvaUkDPjCCpnNrq8cTwCHTmNMFDyo+DvyoPVA02SnZJysQ?= =?us-ascii?Q?TLWUtCx3GZ2L7iJ1VrloW+aBHhU/6XvR4ui1vjIrcqn3fve6IjseLUlIjPAx?= =?us-ascii?Q?6TGcP7509O51cWqEZFFv+gl8aOsGzZoNBfrhrpil5YKBKdESj6n+73eud7Mu?= =?us-ascii?Q?DxiBZtshGAQS8AH/tWSZWbe/Ap4UluAleWuflhj0DDNcIu2LoukOtc+K/I90?= =?us-ascii?Q?4r+hKa7+TU8zjvNXp/inOhDqok9W802a31Aoxe8v/Uv9OYcSO1OGms0NsA/n?= =?us-ascii?Q?LNYmExPZH6DJ0xCHmOdRBAxrjiy9mph0NtehqdztICQbyBy25RGZG1IDOzAy?= =?us-ascii?Q?F3c1ioCxwRM9CJ+/CyxU96sWDWV+AH2zOemyhKAuE3W5yfK7XzeZ0JfaCXS5?= =?us-ascii?Q?09gR9NJOIxZ7QWGZeBc12UyxOAlmjuKeBOp8A6pWgwWvU9fdHCkhS2m+5e7w?= =?us-ascii?Q?wiD0gMXNhPBE0ttxdwRLNtVILwPVOJzOtpb/VeH+TlxM2N9/XxiwlILQBebC?= =?us-ascii?Q?pZtjSEFy+Fo0rg8jllbr/VMiyBMhjDyNKW+jQJLY9ib2QGRexCKznz0u9mdB?= =?us-ascii?Q?5AR4p/SJhCWl0BfVPLkSI1Yxh1GVCuCl/4fQVNSSvq41hsGQgSuaQF9GDJmE?= =?us-ascii?Q?fdtQkuyMABGEKtqywu69xW1hV3ar1ExmMOurKLN1UlsUYzSWkJ033Ljt1aj9?= =?us-ascii?Q?ZB7VZlhUynLfpzAoA=3D=3D?= X-Microsoft-Antispam-Message-Info: HRdNWmLIvodMdggZFdCgCVXwplRJAwCuKyqKKaaNMreFi50EwuKeXpG9bL5GUyLLE4wpgvziUh/7i3hzUonpj1mewE2VZBM5mbPzq11h79nw8yl58s4NeDqet39qEdAmCqCtNUQEqDrRVBXEs+28rpvDUa2Bfejog5gCmopKvLoJZievxY6HAQf7S8MCB5Dr17QVUCrHZdgQZ7n/zh+9RjkmXWrgl1bBeU0SfCNe9OBoShP1kDSiyk22r/MTjNSy X-Microsoft-Exchange-Diagnostics: 1; SY3PR01MB1273; 6:81lifedIcUcIVOrRURoaEcDN96W71a6wYAo+bDtiZ+biNpF0tCizjguhzrqzQBToym/mnGFt6euP77MWhE4U6GSLilYkR0AieN6vwQBKEqoTRKOEYKxVWOeSqNFVH4g5gHYpaOY71i1tSmSmGC6lvRFaima2l82ihpwtwsFShgnYQUqnl6tAuAGbl9P/Xp2vSkbXkA6BQTdZEhTgXMTAN2KaFrL6Y3AdzLDGvPp8IJK3fjV38l15YxEY0NNS7oyAvcwl5vqydWPyIOsmRBcMIQFH1Cq7chY6J6YM3hOn8toTfkYbryEU8sxgj/VCg2xdmlhxe3iHkJ6dKh1Oa7RQxNOMzLPxWpL+BkxzSxRqmAr1MOp/pPyNkG5mz6uuQjAHIMQSrjlSlKFqvyUBbkcBOjMD5uzJ52Y+mADb0hJ+amMk9gT5q9DgpajyrWGuhbmrtWlzeALwQP4y/Wy0qK92gw==; 5:7GUg0MenTUtKhYNf+vp27xChdr0iDD6liBfaC4DTPRmGyNWBJfk7EU6fSmkvgzP33jUo8qd7YbVoUVeX7EbP9dROE/SaO4xvvA0MGfnoOPszsfSlYbjlP1lKAFEAsZe2qCDPTYGj6kt8nT7GJFWIVENUMy53VNe5S6WIO/HRRjY=; 24:U0k+VrklO9ZBLNVntIX9hwgerKK/X1Xal/SqJDedTMN3Y5u9A8gpiejiSoU4zjQoZlJUmY2h0s/TXpC1cmPcJHpW1fNN2qiFh2BmtNvgKlM= X-Microsoft-Exchange-Diagnostics: 1; SY3PR01MB1273; 7:JO2szLE1rD4io4wxj/MyMn1NBbmAg4zrDBpeadsPgmi9FZeC6E8QUrlscgJ6L3G4CgsxcZ5xLEC+Aqj7Nut6IgEMozLSJjndPV1vW2ZE1znzPN5+is8WAorYjm75wXuos7yCgZlNSVBwFLn/yJ3cvxClyTay0RXTGXGxSo3g1AoBXM3wdE8s0UN/VGcq27CpkFJIU1uRvkvgRab8O9QQ9/cIh0Khq9nV/IKRKdfDoVajpLJQkyUN83Q74bdQ4YBM X-OriginatorOrg: Vocusgroup.co.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2018 21:45:17.4156 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 170a0e99-b347-4aca-c867-08d5cfe49fea X-MS-Exchange-CrossTenant-Id: eec9be44-7631-4cdf-b8ff-6faef2502ea2 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eec9be44-7631-4cdf-b8ff-6faef2502ea2; Ip=[104.210.80.79]; Helo=[au1.smtp.exclaimer.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY3PR01MB1273 Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 21:47:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_c07ed87f-3415-4257-a3a1-89f4081b9f11 Content-Type: multipart/alternative; boundary="----_=_NextPart_662e5284-1137-4be9-92bc-e0384ab29bf2" ------_=_NextPart_662e5284-1137-4be9-92bc-e0384ab29bf2 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Fred IPoE Health is something we have struggled with. We are a NZ based ISP with= a large IPoE customer base. We are currently running our BNG's with 5 minute lease timers to try and ge= t around the issue where the BNG declares the subscriber as dead and kills = the session, however the client remains online until the lease expires. We have had discussions with our CPE vendors around arp detection/resetting= DHCP however those conversations have not gone well, with the CPE vendor s= aying that ARP and DHCP are 2 different things and can't be mixed. We also = looked at doing something similar with DNS (3 DNS request fail and it turns= DHCP into discovery mode), and BFD but nothing really got passed the white= board discussions phase. If there was an accepted RFC we could point the vendors at, it would make t= hose discussions much easier. Cheers, Simon AS9790 Simon Allard | Development & Operations Manager D: +64 9 550 2790E: Simon.Allard@vocusgroup.co.nz M: +64 20 1000 790W: vocusgroup.co.nz A: Level 2, 1-7 The Strand, Takapuna 0622 ---------- Forwarded message --------- From: Fred Baker Date: Sat, 9 Jun 2018 at 22:58 Subject: [v6ops] draft-patterson-intarea-ipoe-health To: Cc: Looking for comments on draft-patterson-intarea-ipoe-health-00. The authors= would like to discuss it in v6ops at IETF 102 (Montreal). Do folks find it= interesting/useful? The primary working group for this will be intarea, for reasons related to = the charter. However, it would be useful to know that the problem is a gene= ral one, and get comments on the proposed solution. Sent from my iPad _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------_=_NextPart_662e5284-1137-4be9-92bc-e0384ab29bf2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Fred

IPoE Health is something w= e have struggled with. We are a NZ based ISP with a large IPoE customer bas= e.

We are currently running our BNG's with 5 minute lease ti= mers to try and get around the issue where the BNG declares the subscriber = as dead and kills the session, however the client remains online until the = lease expires.

We have had discussions with our CPE vendors arou= nd arp detection/resetting DHCP however those conversations have not gone w= ell, with the CPE vendor saying that ARP and DHCP are 2 different things an= d can't be mixed. We also looked at doing something similar with DNS (3= DNS request fail and it turns DHCP into discovery mode), and BFD but nothi= ng really got passed the whiteboard discussions phase.

If there = was an accepted RFC we could point the vendors at, it would make those disc= ussions much easier.

Cheers,
Simon
AS9790

<= div style=3D"mso-line-height-rule:exactly;-webkit-text-size-adjust:100%;"><= br />
<= table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"border-coll= apse:collapse;font-size:14.67px;color:#808080;font-style:normal;font-weight= :bold;white-space:nowrap;text-decoration:none;">
Simon Allard=E2=80=8B | Development & Operations&n= bsp;Manager
<= td align=3D"left" style=3D"padding:0 0 10px;vertical-align:top;">=
D: +64 9 550 2790E= : Simon.Allard@vocusgroup.co.nz
<= /tr>
M: +64 20 1000 790  = ;W: = vocusgroup.co.= nz
=
A: Level 2,&nbs= p;1-7 The Strand, Takapuna 0622
<= /tr>
3D""

---------- F= orwarded message ---------
From: Fred Baker <fredbaker.ietf@gmail.c= om>
Date: Sat, 9 Jun 2018 at 22:58
Subject: [v6ops] draft-patt= erson-intarea-ipoe-health
To: <v6ops@ietf.org>
Cc: <inta= rea-chairs@ietf.org>


Looking for comments on draft-patt= erson-intarea-ipoe-health-00. The authors would like to discuss it in v6ops= at IETF 102 (Montreal). Do folks find it interesting/useful?

Th= e primary working group for this will be intarea, for reasons related to th= e charter. However, it would be useful to know that the problem is a genera= l one, and get comments on the proposed solution.

Sent from my i= Pad
_______________________________________________
v6ops mailing= list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops<= br />
------_=_NextPart_662e5284-1137-4be9-92bc-e0384ab29bf2-- ------_=_NextPart_c07ed87f-3415-4257-a3a1-89f4081b9f11 Content-Type: image/png; name="image664000.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image664000.png Content-Disposition: inline; creation-date="Mon, 11 Jun 2018 21:45:18 +0000"; filename=image664000.png; modification-date="Mon, 11 Jun 2018 21:45:18 +0000"; size=27134 iVBORw0KGgoAAAANSUhEUgAAAVQAAABLCAYAAAAvZX9PAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA B3RJTUUH4QcDAw8PpDiufgAAAAd0RVh0QXV0aG9yAKmuzEgAAAAMdEVYdERlc2NyaXB0aW9uABMJ ISMAAAAKdEVYdENvcHlyaWdodACsD8w6AAAADnRFWHRDcmVhdGlvbiB0aW1lADX3DwkAAAAJdEVY dFNvZnR3YXJlAF1w/zoAAAALdEVYdERpc2NsYWltZXIAt8C0jwAAAAh0RVh0V2FybmluZwDAG+aH AAAAB3RFWHRTb3VyY2UA9f+D6wAAAAh0RVh0Q29tbWVudAD2zJa/AAAABnRFWHRUaXRsZQCo7tIn AAAgAElEQVR4nOydeYBcRbX/P6fu7ZlJJpM9IQtkIQvZSACRsAmEVQQEFVFBeSAKiPoeihsIKrjw 3EVFQMUFUQGVRZBFUIQQwhIIS0LInpB9mUwyma27b9X5/XHqdncCShT0B7ycf6an+y5161adOud7 vueUqKqyU3bKTtkpO+UVi/v/3YCdslN2yk55o8hOhbpTdspO2SmvkuxUqDtlp+yUnfIqyU6FulN2 yk7ZKa+S7FSoO2Wn7JSd8irJToW6U3bKTtkpr5LsVKg7ZafslJ3yKslOhfo6EFUPCkYYDvkHAi9P Id7miKB/7wcCftvfCXbflxHvPTmVWVUJIfBqUptVFe/LBC3FNkEI9r1Str/b3TeEgPfWdl/O4nWq zxVC/jfE3zwQXnTfqmSVcyvv4jXC3q5tZ94Xtf8HFHxAfSBDyVDUB/CBgBJ8Ga8lQujAZ50EPAGl 6Ld9/xmgIQMtx2e381W9XY/qeNymDZRQSmReCWp97bMu+77mfb3U59cjRV52Evtf4xKoLHuqiiBA GaSwg+fbpHLOEdQupfY16pQUsX+coOrJxJNqQtCExNXc/O+IqiIi//rz7YDkE9vu41AFu+Xfb19t u0LIcC7d7ruAcw4lIJVr1F4vVK4DDhGpOb9W+b4ObJK4UKqzZ5d84XSCAgKgHpUEFEQVnD13dWwo oqAuw1MgDVrpD3UZirOxqVLtoyDghIDH+QR1HhGpMQQcjn/v2PlPy+tgNPzflrHvvRqbwAEVCJqh UmB7i+rvihNTpiHDScCToaIkLpCoXdcGvSKSkGoBEcG5gOrLD49/tzK1eySIJOTDtXrLv9++artM cUJARFE1JemcQ9WbMg3YKqNaY5U5U6YSogWcgW7/rK+T6eNMsb3U/9VvEzQEkBAVaFx4XCBoCREl OFBSUgCnSOLACUIBR4J6ByIoAZ+5qiImQRN7jwHB+QQXEuQNaMql/78bsFNeToL5l5LgCCBp/Nbj wnYT5e+dj8NJSgiBxNn5qiDq7FcJuIqyUsx5ExweSP7pFudOz39C2b6sBAcuVKwpEesP+z8x480p DgWSbewlU+IJ4jIgNfeWgJAr95e34F9L8lJvQ9XjxeFUcZVFhIqV6UICkpiXo8L0eav4wR1zmLOm RIc6snjVAhkN6pg0tDvnvXUU0ybvZmNUCtZvYhasQwlOcKqoZAg76Gm9TmSnQn2Niw9EV0wRiUaS 2kDFBV56mlQl4AHBqVSssoCSqEQlDSECCdiREBzOQRD/L6mLf68izS3zHWyZC6gKIrkCBILSsmEL d902iydmLGDJovVs3VICCfTu150xE3bjwEPHc9Rb30S3XrWWsSlYgwtA1fFaWDNeiYgIiQriNLr7 AniQhAxH4gKKMmvBRj7+s5msKjrAERBwHqgn0UAZJZOER9Z28vBPn2aYPMm3z5nK/uOH4EQqIyyE gFSgljeWMoWdGOprXsaccjULbzjXbEWXReWQxAEJO6pYFMPOggvR1XKomE5WJ4R1G/B1jro+fSAI wQVccDtgAf+n5Z9UqJVz7Pi21nZ+8r17ufuWWYTMoxLwXiMsUD1eRWloqOPUD03jfWceTlKw382y VUJcdN4QEhSVUFkINUc2tQRSx2W/eYQfP7oOpECQQBLxZJXEoFYJoA4hoL6MzxTKJaRY5IOHDefL Zx5KwKAaCYrmFnDEZ99IslOhvsZlzHt+xIIbz0OUGvf0nx+E6gOaiFkgAcRBKHax9e6/4je20jBx DN2n7lMd4Gp4rXOvbyemNuiybOE6Lvyf61m/cgOiiWGoIoiLEfJAZbJXpoUTxkzYjW9eeTo9+/ZC 8dFSzTAl/frWqgooFuw0Jz9+Vk8Qx39f+SC3LdxqB0tCRolECzUjMBBchIWyIpJlUA5QKkPowmWB t04ZyjWfe6sFuySJbASPE/OS3kjy+h4N/wfEeUFCdL9dMAwKhei6v5yoN0qUOK1YCdnWTTR//Wo2 fukb1I8ZQ98PnUL3qfugTqv0KQF5zSvTHQjMqYcAyxc287HTr2L9is2AGHRi6AaeyHqQKlzhEETB qbJo7irOO+MqNm9qq4EzXut9s2MiZEiFk5eZMg2m+H7wuye4dcFms1hFcMHjpC4GrsyqNSqZQlZG yh7JFC0XIZQQb4vy3U8s4xu/etiUZ7SGcQnsQNDz9SbOUzReWR7dVJtQwZauilS4YcD2A9lQFvsU 8IbTKSjl6qTfjkcZql9EnC/SYwLW6ert5wo3Mtjn/LdtDOt4l3jPnCOX8xaVMhoj5XnTazl2PtRw 3tTX/JYfnN8hq/IPgxIiD7LyfHmb83bXPoOWa1rrqxzBl5HgBBy4SiAkUk0kwSFmeRKsm16KNurE zpUE195J89evYM3Zn6bx8Dcz8H+/QMPEUXZdZyED0Ro3fztO49+Tf8XJ+Xvn/HMcxB2YkCJ0bO3k wo9fS1ebBzHLUqICHTK4Px/51LEI9eCE//7MSfTo0YiSolIde2uWbeJrn/stBMlHlrUx6DZjqrb9 WnmOQKD6/qtPFrmeIbIPqB2XWfX42u9CTf/UzA0bT9vOC/U5ZznEaVdtQy10IiHipjjz3iWwYOUm vvuX5QRXsGs6wTsgZAYZBZtRKtAtgVFNDs2KaLELFzzqwfsioaz4csaVv3+Cecs2EJzRqRxaoXG9 kST98R3zEe9jtLcOIWPqpEHsNWIg6hSNiEqIkUAhgAh3P7aMZWs2452Selvxhw/qxbH7jTTrBoAC EuCFDVu4dfoi/jZ7NXNXbGLzpiKaKgOaujF5bD+O2GcYJxw0il161duipaGCsQRXG1W1P6KG2aiU 2dzm+cP0Rcx4cjlzXmihWAqkBRg5tA8Hj96F4w8Zy+hdeyEiPPzsCp5ZtgmwAUwIHLHPcMYO62PX U1BxOJRiKePnd88HyVANOITGBuH9R0+0HnEOF1LUCd57/vDAAu56ZAXPLW+mq5jR2Nid0UN7MHX8 YN52wFBGDuoXx3YWo81qA/kVLtKSAOoIBEhq8S8IouZWEdjyp/vZ/NXv0nTyCQz79dVo6ixyu10D KjjadvzSlwo0/TMc1NpjK/zF7dgAf+96OWf0H53792/suPbKP7N2TUukTTkkCaSFAqd+6HDec+Y0 NjVv5Zpv3okgnPiBAznkuMn84of38aebH4mkdYeI8sQji7n7ttkc/Y4plTEZnPE2xULjkYuJ4YkE YxIEVwkIWpuT+BzGLRCXc0MFlQTjFKQVvKJyPKlZ1SHDSUrEZUA8QsHaJLnbrpA4iFervuYcT86Z DlTaZBQ6gIQLrnwQ370OEY8TCFnusVhyQLdCyl79U1wq/Pa8Q/jrE0s558czcRogBJKyEfclBEJI UC3xiW/fw53fPw0nge0ZFW8USR99eg1/nLkIABXBIRy+zxB+d+mJkaQLWfCkFr0AHG0lOPvb97G1 o2grfXzZ3/34YSDVVbl5S8alP5/OjfcvJgveLJ8sIImgGazZvIU1j7bx50eW88WfPMpZJ07is6fu Q2N9neFbzhFISD2o81FRJ6gkdJYDX//tLH5++1zaip0VbMYFU+5L17Txt1kr+fINj7LshnPo2VjH 7TNf4Jo/Pg0ONDicBvqc38TYYf1AggVtQoAkobMkXHT1/bg0wauCTxg+qIHTjp6CqDfcSYQX1m/l 9C/fzdylG5AAPgVXVjTdyvPL13HHQwu55FrHYXsP45oLDqN/zx6IehBHcD5anv+6KA7wFijwIEkG ITHKCina2cmaz11K+dFZDLzqO3TbZ7KdpwAeVcfixUtZvnw5+++/H42NjTz88MPMnPkoH/jAaQwc OHAbhVa5b41i25b0/hJtrPntzjvvZMyYMYwaNepF16w9v/a6tce93L22l00btnD7TY8YTxIPeA45 em/Ou+BtDBjYh0DGvX98AsERVHnwL89yyBET+cQXTuLEU/bje5ffwZwnl4AKzsHPr76bo46fjCtg nMsQqBAIJFoSYkpMSFDKMXjlKos1muOwNiVyCxA1RZjEgI/kv0mGaFohdFRw7UpfRF5yiNxSlyEh KlwHQUvmqmtKTv6071JsUdCqvlXPwhWbeXKTR7unJMGZe584dutVYO9B9Ty4vJPHLzuK1WubufCG 2bR1dDB78XoUT8g8PQpw8pETOf2Y8Ux/ZgVf+umDBDxzlq5n0arNjBraFEf964t2tiPizjphMnEU IKoEAvfPXs3ytZuNs6ee1AkBQR0EEf744Dxa24sUVFARCiT07ul477SR8bKB2Ys2ceBHr+c39y2g bGk5qGZI4ghe4gB3kVAOXeUiP/j9LKb99y0sXbUFL9bRKQFNymbVxQG6YkMHR/zPTfzoxtm0F8sI KaL2axBz5xJNUA0IKarmpiWRj0hQEm8K3nCg3IVLSFwB07hlfOIIQY2dlJhlqRi+hCjNHZ2866Lb mLNkPV4NnFdVSFI0DhkV69dVm7bQq3cDuDK4BK+ZRUhfoUhuBaFYoktayYzymzfxwskfpPjUc+x2 86/ptvdkgwjUg3gjV4vw1FNP8dOf/pRbbrkFgIceeohZs2axcOHiGhL8to3NFdr2iu2l0h9rj7n+ +uu59NJL8f4fP3x+z/zcZ599ls9//vN0dnb+U/3z59ufjOmx5g4fefxUvvCNUxkwqA8rV2/i/NN/ zHU/uhcfmQ+Xnv8rLv3U9bS3b2X3cYP4/i8/xKjxuwBmKW9cvZnZjy6NVw8xoGXzQBDKZc+aNVvZ vKU9dkDBxlZMd1U87e0Za9a0UCyWq1YrxgHe3NxB88a2yvWNKJ+awhVo3tjK+nUteB9dfMkoU6pw PgJKe1uZtes209ll8Iajzu4hPhL2A07q7HPuulfgioQ/3D8X6Z6SaFwpgnDBYbsx84tH8r/vn0rw ZRqSQF1dHY/Nb2Hqp2/lntmr2GtYTx6+4hRu/dJJXHzG/owd0Z+z3j6FvXbvh6jDkXHDnbNJYoBf 32DKFCA9YPJAJuzWn+eWr7dvxHiJv71vIZ89bZ+KK5BHlkWVn989nxRHOThSPFnieP8xk6irrydD mbO4hbd/9hY6usq2mmrZVlHvQJQkFbx6izhHCoriwTmWrNrEcZ+/hfv+92SG7NIDpBrT9gLNzWWO +/QfWLWxHU0sHQ51aLT2xEXMKkRnJyd0B8WHaEQoaFJnuFYNlmpGQ+7iCQkecQKhAHiCJ/aDpSv+ 6KanWLKmDQScpiCBNEBIyoiPtCTnUO+56NT9qQu5wo2Y6KtAYlQVkDKOQsRxM8Q5aO1kxfs+QrZx E8Nu/SUMHQhAe7GdGdMfYu3qDfQf2I/DDz+8orS2brVo7oknvoN99tmXAw88oGIlzZw5k4ULF+Kc Y/LkyUyebJau954ZM2awbNky6uvrOeigg9h1111RVebOncvTTz+LiLLvvvsyduzYSpuffvpp5s2b R79+fTjiiCOor69HVZkzZw7PPPMMSZKw//77M2LECJYuXc53vvM9isUi9977F/r27c3BBx+8Q5bq rBkLDLJxBUQ9Q4f3qXB5h+zai+NPfjNrVjazqbkVJWHEqIEc/479aWxsqrjcg4f0Z/FzqxHqEed5 /OEFvOmgMYi46K0IKxav5qpv3UMQZerBY1m6cC1PPbKc937oYI47+U2oKD+/4s/cdfMTbN7SRv9+ vdm0oZUTT9mPj37+JG67YSY3XDud7r0KlDpLdGzt4LSPHMs737M/Wipz7Y/u5eEZi5h2zCScwO03 P84++4zmI595O409Cyx4bhVX/u8trF7dxvv+6y00NXXjoQfm8MzsF/jguUdywnv3RyRFNTPtbTw8 EJvbRsUzRffXuetAG/EC4BjUVMf/nDCJ1eu38p4fzqBYykASejU00Ogy7v/myWzc1M7l1z/Obv2b 6OyjvOWsa7nsvGkcu//uTBk1iCfmr8OL429PLOMSPdxgBHyETt44kia086HjJvLJa1qQ4MEVQDKu u28unzx1XwpCzJoxS+6ZZRt5Yv4awFwLjyBS5kNvnQzq6ezyfOArd1IqepxLCWSGFTk7v1u3OvbY tTeqMO+FZkpFHz2VBBcC3gXWbuzgtG/cyb3ffDdJkhnHTRKSAGd+6y5WNrebEguYuxIcqCcpQL+e DWzZ6ikWS/aqBMqUUYkulbiI03bhQoFo1uE0yQ11IMehUjTzGOagSJJE7pxZ1tf/ZT6CzxErJAj7 ThzCeSdOpke3lMfmreMX9zzPgD4NnHjgKCK8ZouAZFCLDf/LEpCQWj+ImhunnlWf/gKl+QvY7ZdX ke46GBegVO7k8xd9kQ1r16GJwRjr1q2jZ8/eEde1h//Tn/7E448/Tu/evdl333245pprePDBBwFT rnfeeSdnnHEG06ZN46tfvZwFCxZUWnPXXfdw+eWX88wzz3DddddVlN6dd97NT37ykwoe+N3vfrdi yc6bN58LLvgEN9xwE7fddhvO2YJ2222389GPfpTf/va3dHV1oarceOON7Lnnnhx00EE75PYvnr/G 3rlqJOPbgrtiWTNDhg7gqJPezEFHTeLm62fQt08Pjj15f3Ceji2dtHV0MnBwb4tYSwKUQJUlC1ZV 10JJWLt6E+ecfhUjRw7gR7/6eIUtcP019/KdS//A1tZO3nvmYTz20AJamjv41s/OZu99R7J0wToW LlrNXbc8wY++eTs/+Pk5jJk8HCjz/FOrePLJZaiDL336RmZOf4af3HQBw8cMQCRh2tGTOfMd32XB 86u48tfn8viM+cx5egVnfvStvPMDBwGBI058Eyce+EV+8I3bePt7DwCIc7KMSyBQRkgqRoIZErB0 3Vbo04SIR4KwS896nAQ2bGlldL/uLN7QYc+egJQzBvTsRmt7B22dneCE5+etZt3mDuYvXc8x+4+i Z88CiCdRx4o1my2xxEKgr3Dsv/YkLWbdOPmoPfjSdTNpbcvAFwlpwtqNHdzz2BKOn7p7DGwIkHHd 3fMtEoxHRQgETtxvDLsOakTwfOemJ1jZ0oGmimqGyxyJUwb0rOeyM6fy9sMmUp8YxtTVVeIXd83j q9c/QnvRkyhWCUiUpxds5Kb7FnDq0XtUgPY7Zizj4TlrreVRsSUKvfs4LvnA4bz70DF0a0gA4enF G7ny5sf5w4NLSdXZSujqcF7x4lBnFmQIMZrqLESjeIuji91DXZ1Z2Dm3Jv7Z0LKVDa2daB6UcAYl 3Pilt9HUrR5R5dC9h3PeO/Zm+fqtBLHV2KlEPnNimNcrDUpJEq0MIEIo7X95iI57/0LjYYfQ7ZD9 IBNIYenKVaxfv5FePXtzzjkfZsiug2lpaWHOnOeiq77tAN+4cT1tbR088MB0QLj44otZtGgRN9xw A/ff/wCNjU0sWLCAESNGcP755/PTn/6UOXPm8NRTTzFr1iwAjjnmGKZNm0axWKzAAarK2WefTV1d yg9+cCVPPvkka9eu54477qBQKPD5z3+e5cuX88tf/pJf/epXXHzxxXz605/GOcfHP/5x9tprrx3G Utu2dpB3cojejCPhL3c+xV/umM15nz6eAw+fyPvPORxRhw/K7Tc+zs+/fzef+vK7GTi4r9UScBka UtBAS3MnFlk3Xu8fb3iEUlvGoUdMRl0GmJt/7Lum8osr/8pvrv0L7/mvQxC1vPghw/oCMHxcP0aO G8Q5776CyXuNYsyewxBA1TF+r2GM32sELyzbwIy/PcOwEQMYMWZABTcdNGwAe+83msdmPM/D0+dT Llk4sntjIfZJQiKBnj3rWLemuG2nqHlcTgpmlXqPi+MYySgVM4QSEhyNDY7jx/VGgjB59BC+c+ZA Jv/Pb2nv8jR1T+js7EKd0C2to7No/UIhQbyn4FJQoXlzO07NkOgqBUsmSTA98gbTqa4+SelRn3La UeNQUdSlJN4i69ff81yMjBqno6Mk/O5vz6ESIkZoA/qDx0/AIXRlCb+8ax4uCzivFEiQVBncv5H7 vncKJx8xkfqkCkQ3NKSc+44p3Pn1d9LYIyWLBRcMd3T86I7ZlQ4XhB/e+gQSEkQFoQ4VoV/v7tz3 7ffwX0ePo1u3NGKtsNfovvzkM8fyjY+8xQaYAFomc46QBrtGyAzvFDBLT811Dnl03BgFosSCEsEy iPC0tmHHhaRSBEITuH/2SruVWI58U/eECSP6GF4JBCnjXDBMWnawwMnLv0by3HKHsunqX6E+pfcH 3g04QmrvcORuwxg5bCib2lr55re/wfmfuIA1a9a8CA+tDQg1NzcjInTr1o2JE8czZswYRIT29nY2 btwIQN++fdlllwEMGDAAgI6ODg466CCSJOGee+7hwgsv5LrrrqOurq5y7QkTxlUUYwiBlStXEkJg l112Ydy4sRx88MEAtLa20q9fP5LEXMMpU6ZQX1+3TXv/kQR1OAk2ZkURMjRCN2tXtHDJx6/ju5fd bCm3qnzsA9/ne5fdTEdr0fh02BjQkNo1VFFKmDXnwUH7ljZQT7du9THabkqjX/+e4JT21iJdXSVU UhvfqjGAlAKBLZvaKZW7EDG6oVnxdlxrcysER32P7paCHAQRK3DTb3ATABvXt9pzRXw0x2VVnT1X hSJl1EHJaSBgnl2SVDwHKtWgUhTH2AGNfOT4PcEpKzds4Z1fu9M8RjXs3mdGo+pen5B1WaxkwvAB TBzVn6PfPAYNnr/NXo5IiktAJDIjCG84ZQrgcn7cWcdOQpIkkhkExHPfY6tYvb4rAo+BW/46n9ZO by9EAiKOCcP7csheu4F6Zs1dRUt7ZwwMmfVKUK78xFEM7d+9QmtUrMJPbhFNGt2Pr5zxFlNsWZ4a GZi7bBNrNnSgwLrNW3l83gYQH63JMhqEr51zICMGNUUeJTHamhfA8HzouD3p2VhnlCjnQQJJpoCi GMeuNhUTIDiiRoz0l4i7hiAVDmi/JkdwgooH7yqVc876+p856eJb+c0981nf0omqUFsFz1Gw7yJu 9cqlOlkUh2/eTNfjhlt2n7o3ZTLj/AlkXjnjg2dxxbe/wduOPw6PcP8DfyNJzN1fvXo1K1asIkmS qExbCL5IyEuyhVzRGr92jzHjEBFmz57N5z9/CQ888ABguOrIkcO54orvcuGFF9KzZ0+WLFnCkiVL Kudvk40E9OnTBxFhw4YNLFv2Ak899RQAPXp0p1s3w1dDCCxbtoyNG5t3uHd69myIzCI1zN4JSxav 4t67ZhsnksCshxaiwNa2IvOfWUmaWJDv5htmsH7NJrzU2UKtoInQs0/PyOtMUWDC5JGAMmvmc8Zk wgKei+avRH1g+JghdGtsgOBxISrUNMYlgjBy3BCenb2KB++eY8F+QCTjoXufZ/fRQ2hoTFk6fwVb NrSCE4IWcAEWPrsccEzeOwaDg0c0rVloYhAqXjQvRah4NBilSqMnBvZs4OiNw4vxVhdsLHL0l+8h AN4ri9a0ouUSzVuLEJQedQW2tBcpFFwlYOi9547vns7uw3vzlZ9NZ9W6dlQDwUNDt9zVr1X0bxxx Lg7skbv25Mi9dwUpkzkI3iyon/15DqJlwPHze54DH60xI8Rx7ol7xRGQMG9FC6IYrigAwqjdenPI 5CFYAQ6lolXFIveouRrvm7YH3evTmB5pdA8JGXOWr0eC8tzilhhwElQdzglNDSknHTgqEq1tkqt4 gw0iNUUpm+suGkuGxUiDc7jEkwRTrQHL4FBvVh6VUm+m4BVHIkJQc6v79unB2F17xWcx6wdN8BqY /tRq/vuH9zL+9F/yzkvu4MG5a2sGtOnqVyHAn7/CyoQQoOvZBSTOk0kZGrqTqrEcBKHgEi77yqV8 6lOf4q4/3U2KMmHsBMaO3gMRZcGi+Vz2lUsZNnw4iHDnn+5m+oxHLYEgCGVRunXrhpKSIIybMIaz zz6bkSNHUi6XGTFiBKpKqVTioYce4mMf+xhf//rXaW1tpampiSFDBtHQUFeZ8HV1dThnHM1BgwZx 2GGHUSwWufDCC7nyyisREU455RREhPHj98A5x2WXXcZvfnP9DvfOqPG7ETSHVpR7b32Kc9/9fdYs 3xQXOuME27hUnJNYeDrw7KPL+MCJ3+H5OQuBECPVwuixQ2xhj+/z6BP34eAjp/DQ357jd9dNR71j 3eoWvvPFW2nq28RFX343EMdoEhelWNw6uIyzPn4MjU2OL33q1/z3+3/M1z59HR965w95cuY8uvVs 4IIvvgcFvvTZX9OycStZOeO6H9/HovkbOf0jhzF2wlBcWojsktqFytG9KSWLNXTMCvWRGeJQTSr8 WQAXBK+BscN6k/gSzqVsbSuzdksHGgL1hQTxAVGNrBaoT232dO9Wz9ZSBurZ2NrBAWf8kH1OvZKf /eEx1Bk0kiUZk0cOsX4LO5bY8nqTtFQM1NcJaMbZb5/MfU+sIBWjgeDg1/fO5cL3vZk5L2zkycUb cAl4BVFPn551vPuQsWa9idLS2mUmfYhWbIBxg/tG094ig4b2GXfOCiwYvFBX5xm+S3/mL1tXUTjO FdjcXiTgWb/JAG/1HpekkHn2GN63opSdJmYtikekDnxGlihJjCIKUsFxNEauUSVE60wBNLEcdxQN zpIWxEUeplpue1woAsqXTj+Q079yZ4UgH3ILTsBLQqLw4OwXeODJFzjnHRO5/KxDK3inaqQcvEIQ VQkx48QCh77UTsCTaj2lVeupHzYIo50HCvWOiy+6hMcff5wQMkaMGMHBBx9MkiRcdNHnmP/884wZ M4YJ4yfRr29vmptbOOywQ5g8ZQIb126kII5hw3blo+eeQzl4RJSFCxdywgknkGUZv/nNb3DOMXDg QN7yloPo06cPGzZsoFevXhxyyCH06NGDiy66iEWLFtHU1EShUOBzn/sML7zwAvX1BT784bOYMmVP 5s2bR319PXvvvTfjxo0D4JOf/CQzZsygo6OD/ffff4e5qPseMIqnHp0PJARV1qzeAMCkN43mXe/d n+n3z+O5ZxZjNWAdSVLHu98/lZF7DObXP3uQlUvW09xVMrK6JAQV9jtoD0ugEA+kSNFBH1AAACAA SURBVJrwxW+/n0cfejOPPDiXr3zmtxQK9Rx5/D4cc+JeNPboTkA5+u37sX7NFhp7pIjkqauOUXsM 4hc3X8BtNz3OymXrcC7htA8fyrS3GqXxsOMmssekC7n3T4/zvctvJnUFBg5q4uqbzmf02IEEPOP2 HMZJp05l1Lih5vmo0bA+/rmTmPHg3Br32uIJISpV1FxvjXEAR8rBk4Yw84HFSPdeaLlIa4dxVrt3 q0PLXfgAXe0lHEJ9Qbn7ocU8s3gdoaRk4iiIY82moukBkpjKGkBTpu49BIlFpyXaNm8kSevq62NF 8wKH7jOc0bv0ZsnqFkgdKKzf2ME9jy/nnlnLzNLDVIA44bS3TqK+DlADxBvqUnMLkwQtZ5AmtHWZ G2BWTog0KisPJpG7Z4pVaOtoN7wqcZF2FOheV0dwqSUGeCvDFsoaV1xzZwzjDLFthq+ROFIEH4TE kH7L/Mqj2bmlqs7I1zkRGsiVk9Ocry0Qy45V2o7wtv1249eXvI0Lr32QZavbEAKZCClCAU/AYAFC 4Jo/zmfyiIG858gJlikSxFbuVzigJEhFiQegvu9AxBtneNMPrmTwNy8FPIEUhzBu3GjGjhtl6X+R MB9QJkzckwkT9ySH1w499NCK0urdpy9ukvkBDuEthxq+GUJg/fr1XHHFFRXlNm7cOKZNm0ZdXcrx xx//IqU3atQoRo8eXfl/0qRJTJo0CbBJPXXqVKZOnfqi52xsbOToo4+u/L+j6a5HnTCFn195D77s zSojoW//Rj56wdsYu+duHPzWyaxYaB5EoU649tbz2XV4f1SVhvoCX7voRsplKoHRfoN786YDRplV m+fzR8x9/7eM5YBDxtgQccZXtvCDRxBOPv0t0fuyAK95DsZo6DOoNx/876MjHGKJGTHHCVHH0OG9 OePcoyITJUTuq9H3FGW/A0az30GjKjCahgDOMWXfUUzZN+/v3DL1OBdzICNdSvLYe1BOOGwPvnXz kySFbki5RBbnfcEJ4gOJOh6du4Yb73uWdS0Zn/vhfagaDJcoNPVsIORhC4kVZNWRKrz9YFsgK6ya N5ikqiVLKQtK6oSzTpjAhT+bifgQLTnHVbc8zdML11vl98zwr1SUDx8/xaxOzXCaMmigucCaRf6l CE8ubMGXM6QgSF6VRpOKew4Op7ByYzurN3SiIhg2bnjn4H6NpECfngWcBCPai+WbL1ixwWikiU2w PBvGVtsUUU8sjYthR7GKeA49aEJXVxdQiFSXEI9OaO0q44Kl3BI5siFU3SNT0AlH7zecI998OjPn rua2h5ZwzyOLWbWp3YJ2DkTNMicoV9/6DO89agJ5KqPXqOxfkdjIFTXFXzdlD1z/vvjmjbTffDfr 67vT77PnkTT2Qsks6CDOvJDIp30RfaXyiDVFmcVBy2bKnR2kuwyFpIxzwoUXfpbnn3+elpYWBg0a xO677/6iIFcu/yhtdEcszn+lcHX/gX044eQDuO230yveScvGVs477YccdeK+nP2JtzJs9GAUJa1L GDq8P8uXrONH3/wTsx5aYGPGB5IUvDr+67zDcGnM88nTiF21clUIWPJKHHUieT0JsYVUXFzLYzYU xgpweAIJOe/aEeGpHONMzGPUCt5fzbKLCaxRyRLpgRK53TGldDtPSLVmMVdv7IEYZB4zrC9HTxnK nxdsJknrcKHM5rYO5i3ZYDznAF/46f22/1OkQ9n7q+O+xxbxp+nPI7HmgVWVssDvUVNHMXZEv5gu aztCvCaKkL+KkubWmsbo+HuPnMhl1z9OZ1cJgj3wjLkrEeqs4lFiOOKx++/Orn27A1QU8r5j++OT As77Sq3NrZ1d/PLP8/ngceNjByvqgg0GdZHcD1f98SnDmBw4LaCUqUvqGT+yPxCYNGqgWYtJDIoE pbU94w8zFnPKIaPRfEXE4URsQzGX4jUhyTHLIFU8VQycb27rNMgCw1Jt1EJrezFGhQ3rquY9uxou qV0yUeWgCYM4eM9BfOPsg3lgzgo+d9UMFrywEdK0grXNWdli7k8s5qs5UfYVSCDDkRI0M+ijkNLv Ex9m/SXfAp+x+de/p/WWO2k84XCaDj2U+gljKew2GHV58l90y8ACKlvbKK5ZA6vW0b5qNbp4GaXn l1BcuBjf0mKBjz79GHTJJ2k86W04BxMmTKjpoxc/T566mkf0azOvqkq7yjDIZXtq1Pa1BXZICQNn nHcUj/xtLutWt5gdJikE4Z7bHuehe5/itI8cw7tOPYByMfCzK+/gj7+diYYcF4/GQQjsfcDuHPv2 aD0HRdTFYsnlaI0KLjI+nFSVnFSSU7RqgYZ8ocqNjDzgGeJ5RIZNQBKtxiBq8/YjdcuMXlOQlei5 uMoxPjicGAfb+i6pQS9tfPsQi0kHQRK4+MPTmPGRn9LV1BengQM+9hu62mN+fhZjDmS27QmeIEqi gTO/dJtRCYM3zNkBeAoF4aIPHYrGXSKSmM//RpMUCkglSBLo1eh432HjuPaeZ2xjM+kCSdFQjpF7 h+A558Q9TYkF22vGOWH3QT0YO6Q7i1e2VZQnInzp2ofZe2x/9hozICpQA1gFBw7uefQFrrllTrQg hCBlxAem7bUb3RIbMMMH9mLcsL7MW7EJAwpssHzh6unsM6Ivo4f1NnWoYkVBYr7zFb+fzdnHTaCx ex2D4wJADXD/6HPrAHCxrfl8njlvpVGrhJjWpwzp3yOeDTHVg5bWLvr1rjeXSVNI4LApQ/nRJ47g yAtuIvWOsisZJSYzygjRinGvBijv8uh7Uml/7/e/h+KiF9hy3Q2IQtbWxpbf/Ym2G+60xcB5XK8m 0m69KEtGkmXQXqTc3rbttYMtKOa+1RtwIPVoSwtrP/l5hozcle57T/6HzctTV3NFmsMM2yvXl6Ju /b06Adsr4X8sgabe9XztyjP4yOlXU+zoIqiveEudbWV+/K07ufln0+kqddLeVrJ7RItOsEVz8LD+ fOHrH6gWlXYCXigrFCKdKWeJ5Itvpf3RwDfPxAJe1TqzeV1VojI1tpZz1gZb1CVfg8nz9o2d4sBl tntDfFZjtyj5Vi/gLGtV8+sHDEjILCgVobMkPqgkBm2MGtqbL33kGD7zw/ugsY6OsqDB2w6qFFAt 4oJUjBEhFp6RQKKJ1a5KhRAcQZTLzzmKMUP6Riw16pE3IIbqMg0xKwhyt/iDx04ATQhSskCNt8Gd qJnqk0b044BJg03NqK2cHiAIZ58wxVYukcqg3FLs4oSLbufqW59mS1eZfJfJDS1b+fIvHuF9X77D OLCiiFdjEiTCOe+YFHFGa925J+4FEF0hsyk3tHdx9Gdv5qpbn2ZdSxEEyiXP/U+v4uRLbucr180k C0aZGTakJ2itiyvc/+QK/vrkSnD5gBDWbi7yvRufjsElDGcVGDWoV020PjDzuVXsd87vuGX6EgI2 OK38obBqUxsgZA4IDg3CwH7dEY3WWlCrmvVKXyAJxN0kLV5mpdoGXPpJdvnqRUhjDxJXwGWxdiVG rQktHXSuWYWs2UB57UZKbVstEEmOGVvQKUuSmCabkUQepwUhHVt//8dKO7Z357d3z7e3Smu/eynr tPbc7RXnP+MmSlQww0YP5qrrzmXQLr0rBX1ydpzg2bRpc1SmMcFBAqIZooE99hzKD647l159u1FJ EqCEJFCIMJG6+Bwh1j7AoZIBgSDVbajzAkP2wBbUgtygcahKtBSjoan21qw9eV8b5S5zYNuI2H1y 70ryA/PyflKOM9SRc1+teItU7olajdMc8kKEU4+dyCdOeROuvYiUM8RnEBw+FHFBCUIscRhINcGL RCcwMy/R2zs+/5QDeP+xk60WCBY7cJrw0vUmX98i7aGo3dUwRJXqthcnXnQL059ZbRWoQt5xoMHx w/MP47QjxxNczMWNGRYSUsrqOfL8P/Ds0mbimmoraWJbzdZpgWGDm8hCmeXr2vAaSDRORCfkSOiR U4dzw8VvI99eAYWMIm/7zJ08MS+mTlaKtkpOG6VQKFAuliPwb78t/s2Z9G6qo7ktY/ypPzO4XyO6 6hx1WuLIqXswYVgf1rV0cMfMhWxsBxdKiDicF7wLXH3BkZwybWxlXrz1M7/niefWE4BJo/rw9gNH s2u/Hsxf3cYvb3+cli4smEWKusBxU0dy/cXHVvG2fPD+AxlzytUsvOncf/kF++ZNbLn2epqvu5G0 rROvSSWRIYuYmehL7AJQu3UwZYLY3kFIXrUp0OudJ7HLt7/4L7ftPyGmsDUqIaW9tcw1372du297 Al/OcC6JNCmzsgBCVPL13ep491mH8/4zDycplHBSb9ekDNvwPV/bojEAa0EiqpipuhftQKJ50DXf niQo1981h0uvvov2kMbSe87S1ElQtfRzzKSAiMkrnkKhwGVnH837jp9IEsqoFFApR/5tQmWr6jeQ SEnLWogRbvPGDa+54+Gl/Nfld+EQspzDGZSBvRt48hen0q2Q1rhjtseRWXKepau2cvSn/0DLFm+r Y25pVDioKV4ykhihDiipKD4DnLD7kF7c+/V30qdPwdwDcbgAmQus29jJSRfexsJVm0jyLKd8+1t1 lXtZ8WWPJo6lN5xFr+51iCifuWYGP7l9bnTRTdnl1m4e9c9dL0JAE3v2EUP78MiP3kcaeYR3PrKI 93/tXrPeZVtMLwSPcxaIypwj8VZl61dfPI637btbxT3ckQn5ShVqpR5mZxetf32IjrvupX3GY5Ra tpCSVPYSyi2h/Dk0KtkMIYlWiEdJQ31MrwwM/cHXaTz+6Je5//9viW4wtXtwBZrXbuHu22cza/o8 li7ewNYtJVQCvfp3Z+z43dj/kHEcdeyb6NGrjtpEhG2i+68zqW4umHsPecAKNnaupX+3IfZ/EIPx yKshw+IVW/jaT//KPY8tBslA06g4yxW2AOpjQoDjrfuP4qIPHsLuu/bDhcyw2VRiTKJqlb8+lqQd Fwkh0zxzB4gTLCHLMvb+0K9Y2dxRg7/U8Yl37c0lZ+wbEdCqFWObv8WonXpmL1rPaV/5M2uaO63o rBRsIoYqvhSbYNFwb6vnuGF9+f2Xj2NgvyaSPDstDgLFtp9dvaXImV+9i8fmrcKlKSHzlcwjr1kl MKAkOPUsueksejU2oOopdiknXnQbsxatRzWQBME7NdDKx1XcaAoV96xnD7j9q+9gz5F9ILHB8PbP /oEZz62vYoRZFhWkwRW5QrIsg4TTjtiD759/mEELFfzo5etBvlKFWmud5HQbgpItXEbHU8+SzX2e zmUr6Fy4GG1uhlIpWvfOwEMXM8miZZq/86YPvJOBX77oxZbta1byXR0izayS+GHy955CKSMUbLdO yRdMKp9f+xZWHlR128w7WxgioK+OeZseZny/AytKF5xVZ3NlqrtFBBataOHWvz3PzKeWM3/pejZ3 WuGYpm4p40YM4MC9duPEwycxekjvCIGUCcFBkqBkZsVa5JnXft/98yLqg2qethmdUPuc8a0bnuZr v34YCQl5LOnpn32AXQc0xfdkbkGGUSdEjASSxBW9ubWTL/7iMX5/3zy6grn2Id9iQ70FKOIuiA31 KeccN4nPnTqVugYj+wfECkY7YkVzbHWUAr6ccdXt8/juTTPZ0l4ihHSbbY9FrIq9qJiF2qO+8oSd Rc8XfjKD6+59Pu58WdMhFUvE+IP7jRvM9//ncMbu2hcr2mxpmW2dGd+8cSa/vGsere1ZfCaLpqoG NDjEBerrHOe/e18ueM8+pC5a8v+EGnqlCjVvc/WzwSqK7bMOlpQhCOIzSs0thE2tyOYtZG3t6JZW EKEclEQM86qbOJ66PcaAvPIC2f9uqVqVtZM3x65dzTGy3Xm+Yo1WijxjOfaQwwivn22kjWue07ks oy+JAVfVMo+tuI2pw06umf1KGnfGqMA/onExsaImGsdWUBtDDmP2BDRytqMNKoGgIbIrch4ub0gT VUJQjVRGoyORWDEJHM1by9z76CIMwM7o06s7R71paIzUxpRHje5BpfPKBEkhEyS1Tl+1vp3bHlzG A3OXMX9JC62dHnWefk2NTBrWl7dMGcI7DxtL354N1iiwzlaqylSEfD+g3DomKMXM89fZK7h31jKW r9lK8+ZOXJqw+6AeHLjnbhz5puEMG9QD9aG6wWIk1a9qbuPumS/w+LxVLFvXRlexSJoIA/r0YJ89 BnD4viPZd/QAqsGEshWoiNxXwdFezPjzY8t48NmVLF3VSnNrkbTg2H1gL/YbvwvvOmIUfRu74yTS V1wZ8l0j/0MWaqW4i0JQs0ACYlSdOKDzpXTbIFFOMt8OY1VPyL2a18G+QNUdB6oUOMiDb+ZVAKYN 7EN+pgXx8mLhOby1g1larwmp7HOWWBwk0vaq+fTQWtrAE6tvZdqwD6GujGpdJfkEJzFoncUAWA3O mt+CcqRAmhUqzlUw6xARVlFXUc62n5y8Lhbkf1YkhExFkkpHW0f4SKmoUiECgovEYQn5BluhEkW1 ztPK4Kumm0UF6AJBHV4yCriYcOS25UFCDDRJ5N9BrrhzzDGgOC+EJA4KpUJIrri3EheH2FZxKTmJ Paep5JMDheA9krgaRVI7YSKtRU27B2fbUeQUL4vV2cDJqTA55mafzYrJLYRYeSUOrJcfUK9YoRLV RXxnOeRsBVNCpQ9Q3UY5VoI5gHgHSe4yK1ZDtkZRv4YlL8pYqyRN4h5igHE7TcFUPDWtusQvLmIT 8N7HClivdbc1ixCTxnToQMD2h8uDTmvaF/HEmj9y/JgLKuMliBVyMWPJ5lkkEUTvJjcyiNWjTEla AoPdtwIpULVMAxorVeXjv/DSzX6dist8CYjlzfKqQpjCyHLeXMg3H8srM5nLntOfVIJhTDFTqcIn JYlV6+0aTsBlsVhHElPggikrVW/KUQI4CwaFqDARA7ODmhGhThE8NljMejVlboEH214hwWmCuJSg VCKRkMYgZwJqdBJJa62vbYNFqoLH4dWiki4UKgtKrkxxUt1yOdhqbNuuGOnZxmIao+M5apfxn6hW nnMdbMNFc9mdGaeouOpBcbCHCt/RIAwBQuIjsdxVlank2wi/tkViYMUkJ8JXYR3bVHb7cscWZDGu a26dVik+ltWZRvf/tS5pZRF0ABLY1LqQ1s4NNnsEOsstdHRuoSyxmr/AspZnbN8pjZmFLh+5VjzI YwZY5qxUITEV1lUyw1K8BovmA5X9fqKOCZm+4ZQpQJom3YxHJ44k7see7za6qSujuRO2Rh5qr0LC bt1TuheqQy+gFaqVZYiIuZVYJohK3NvJ5UaQIjUrf5C4Z5PkdB5L43OR+6kSwIMmNnlbvbCuI2NL FgjB0zd17NLUQFNiinVbW0RjOyCNARYA8tRAMddbfawRKTV4YryGEPM5HIY7RY4hmlt8edAnWvEu WteSQKRnIZA5SOMuqYBtuhYXg3+rxILd1WwdjNNIVPyG9SBSLTNoAb18YYn7osbFzpSqqelXp/zg v1dkOwvypVz1l06F9XEhh5wgnzMGXN4hrxMAUNSRiWGiK7YsYHDv8Ty/6s+4Vsf4wUfRUW6j02+h EBJasnU8sfxm3jLiTDZ0raZfw2DSpA6Nxo0l9yiJM2w5FUvOkZDDIb5ihDlJzTjKF2NzdwgEq47F y0NerzdJ8yypJD5ca8lz99oOnljn2VLOyEJAnMagkOWgj+7pOGZoTyb3TqzcWYwE5+D/9Yu2sLw9 gGh0sIzEm6iQpIEeScqQ7imT+9Qzpld1i9scxxV1sZCzTWjvAtPXlJmxrsiy9gxRT3AJieZbsLQy tkeBA4Z056B+9ZFjp4YfiZhV5QI/eK6VzaW8yK6Vs/vsRNti2oJrtjWDBM9vl3WwoLUclYngJeUT 47vRq2BQxjfmduDLmVl1TqK14nEEClKgvk4ZWp8wsW8D43unpEh1S2z1WGWrV29CbpNVVOuKO1P3 tdPfLCxX+c4yoWJ6DhlIGuktGq2bvP4BNbjvy0+Eaptq143tccparNb6pbZbaku8VTHePIuqNk89 i7jcS2OcNq1fOhiYE+GV2uBsgiPHEYl9IJVAyz/EUNXHPP3q/9RQlCwOsO3C/a9K3nf/+DshVVBJ 2KVpBLOW3sDUkSfz0Au/45a5X2FA92F0lpuZt/4+nlp7D++cdCkrWmxfr10aR8YrmKtv5VWr2W4V qbw0R4W5E/+vLuREiCupOfaNJamqWlqbg0c3lLj+hS2UivmAjJZmdLuDA/EpC7aWWPhcC28aVODM 3XtTpwmBIpLYqrOhpKzsyOImX5CGMioOdUogg1Dm6c0Jf17Vxh59Cnx4TG+6FaQSbrIKUg5Embe1 k1/Ma2dTOVoRWobE4bxa+qAGnDoWtJVZNH8rf2no5Iw9ejC8MbqnolFRO1Z3BDZ0xYIWGuiexrTZ uPqmcYB4EVpKntXtRbzGiUWRzDWCEzwJa9qKtGUBnMTIvpJoAS8eCRnBCc8r/GV1iWE9E84d25N+ 9Ull+gcyrC7VK5SIfef7JokVpKWaC55jxVpZaPIAjWG7MQ0yCOoCIaTVbY+pKsL8b1U5VjNztsWw a5gSWi24USXDV4ND+TXy451oJfBoUk3PDSGAy8n01cIeOTIegm1rUy3RaFi3xsXC5dgvUKmoE58j r9kkhLgttKs+Y4RyqkpBUB8giYq+UjDHmz9kuZyUg6fOGUugupq4Cg7tRC2V070yTmut4qym5G7v OcSXplBIGhjSZwq3zfs2J+3xWWa+cBP3Lr0KJ3XMXH0r75v8DZa1PsPKlqc4fOxHqLUi/9Eisr2V /7oK3L2KYswZJ9y9qoNrl7RR6hJwjiw6z6L2OQiELLcWDGOatT7j6nlbCYkSkjS6wo4yGUEyEgWX ZWTO4aPrLqFAKikulBGFBZtLXDF/SyVbx5xnw2EfWpPxvWdaackcCRlOHXnFexElU8vOsDTXlCCB 1V0lvj6nhWc2l/CSWxTBAmuR/oKEiClmlY5QNbK6TWyHBkcWHAmGpQUx2hEEUtNh5KmGwZvyCloi IUGlAGrVpILLWNZW5PJnWugsqy3kkuBcbgW+QqnsTlDNCMqVVP6eDP8L2w1yw3kr0W9naiVxWQ3c ESoTBYhczLy/JLrFoYZqJtt8xuW/gVCo9BfbYY85dq+aB3lqfg8S21mreKr9ZgkcFsVPMOKyRebN RMqtJBubhoP6vHRcjovGPgMHLsUHVzmP7frAvs6pZw51UqnfW0n5xFHnhKDW5qB52m1A1GPYkkfl 1UkQeOkqXIFKSqoEbOdhg0CG9RrDgB5DuXne5ew/7F0cMepchvQYzalTvsmy5lk8uPRXTBv94Rh1 kG3uU9sXtf9vX+Dm/6IyBUgdwjMtndy8rIzmWU2akcRtkbvXJwysa6AtZGxsD3hnCslpgUw9z7UU uXtViaOH1lXKozWEOpx6ggSrqxqUfg2O1qKSxRJ8KgXKKKnCys0ZT24qs2/fuoplMGdLkV8t2WoG QMgoJymiGYon1YLVTXWBoPWoFlEcTgNOGihlGT+at4XP7lnPyEbDacFeutNYfCI1FkPFIakMAHPL E1UKYguBgxiht4mnqMEc3ra6kCBISPCOGPhJSSU1aye6qe0+cPfaNk4c1r0msv/KXZ5tCU01lhWQ 18asENjjpLaPucssFZfUjkkMA8uvXXO9vLCJXdOAour/8hKfcys3L8rhUKkSzPPqR7XXrHI742/O PAwfFzpUX/SMktd1zYutuJQn13Zyw9NFetQLw3oXGN8Xxg1soKnekA2vASd5smRUclhVqXxTyryP qouI5g2tWurxQ1UBV8XF53QSM85i7QaRgJK+KgSJKj/UV6xTa5ItmO3lFsrFNlp9C21+I8XOLjpD M1tKzcxb/1cyl3HyHl/ggN3eydwND/LH+Zczstc+TF92HQ11vWgs9KEhbaSxri896nrTkDZRkHrA xn2eNLZ9gZsqVe3/lqQhwA1LulA6gQJ5sKHgHO/bvYkDBxQwHq9jWVuZny9sZ1VHF6JFUnFkznHv qq0cNag3JA5VRzkxty1BySJed8nevemeJCxrzfjFwi2sKdpeTFpIyLIunm0us3e/lJSErJzyywWb KXsldeb4JUEoqzCwoYH9ByaMaGrAK6xoLTJ9PWwtl/CuHstsse0drl2wkS/sPYC63NrGlIuTFBey bRCsHI/LB4V3gUw8Sho39FNSrWbYBFUCjiRY4ZC+9Y6L9+5HMcvYWBT+uHwr81qDGQdqJf6ebClx 0rCmeMe8fPArFJEqJauiBJwZJpFXadWAIuVNo1JyufVluGOlTEcEVkOIGLaTmKTwYstDNaKOucIh uv+59V5ROo5YBiAqkzywFZMNatI5Kzi6SFwsrFJVUs3YoHpDT8UJ0byCU2D5Fs81D3fipUxzm7C8 JWP6UqhzHUzYpYG37OaYMqQ+egguD10CEVsOGTbot8NjpcoZEDxofn4spUdiFmje9qARJw8kIVSZ ILG3XsTv/Zdev/VHpVh4DoWT0dbeSmtYT2dpM+1+Cx2lzXSV2thaaqYja0EkoaNzPd5vpVBoorVr E5JBu29lU9c6Gn0XpXI7jQ098aFEsVykR12JHt36UJ80RDhte/w2Bjj/DypTgPTx5nY2dAWz+hyU MXf2vIm9mdiUGrEe20lxeGOBT43vwSXPltiaKbvUpUzbpdv/a+/M46yozrz/PafqLr033dBsLbKD yCYQVxQFEwluCYq4ocF9ybwxmtXR0cwkUTKamEk0jGvcBReMoqAisoqAgEEBWQUVaOiVptd765zz /nFO1b2N6Mz76uczDOnnD+jldt26VXWe8yy/5/fjxG4xYmTqg0LbNFxhn39hFJ7ykJ6gR2GMc47M 46GNDYRZmC8kNa1pPJMDAhbsbaZWaXzfQo2USiHwOLVLHhf2zsV36AGBZHiHBGd0h8e21LOmKoWS DiSjFZUthpXVzZzYMTdqmmkBRocgKvuvtRCM7CgyhGdT8zACEPbCGBHOI7ud0d7rlAAAIABJREFU WATWYRhBrhTkxiUlMcmVA4r4+YoKhJdwqXKaqgYs5Erwhejs/9ciFQR3jyLgOUSgdftsZ9jdRShF IEOMsW2TYEBLiUS2aVoJ6QDuwird2ijS/q1lKnLpfpggZsOx3DkKNxUXRpwhZliGJQnj/kzoEJ8T uRo7xBF9k/nsLpoOMJZCz73ouTVNpIQA4pZ304ASPqkgzYc7m1m926d/SZrJwwroXRxG21npqvSj Ywk3HWYp+PxMgy/s5oawqpBCz9X+jYE3t6RQRlOc43FijzhLP2mipkWQGxOM7ZP4BlpSoWWVQCJW L4+C/BIKKLaO23j2Pnh2I121+03SppULj/4tS5etYsO6NVx3zfX4nmBL5UrOOurnxLIzhYNZVuT+ Zcxg/2gmV9doJAGBhLSyT/KxZXkMKBK2U2cs7ZcQVrOpIOEzpXchPx5YxG9GduDb5bkkpCu8a2Xr VlIjlAZtkEaC8ZHRfLsiGQLghXYUZz5+TEYLbfneVjxj601Ge2jpMbw0j0v65EdTWmG2JXVAIgZX Dsyhbwe3WwqN9iypyvLKVhcMZdJd+96SIGvJ2p+5he4adTIcd3V1P6Okw806EuuwoYcCz6aqQlhZ 6eKYwYgEgUqhMSgdJ+3QBEq4dDw8/te5gdI1bFy9GyzlYCDBgSzdR89EWWlDNJgBErQdMFi/aQe9 +n2HJcs+4KlnXqHvkO+xu6LKxVG2vpk9qBCWGMLaYW1NI7U1jVG9MLrWniUgNiFHQIgIiVJ/D2Q6 ug9CeCgl2FtZTatymlkHWaghx2gEIzaSAMknta3EtHbNRFu6kDqNL7BEOwa21AT8dkEdC7a1oLTE YpJB6LTt0rvd3uCjtYwiens8G6dqOwqYGYs2Kqqv1jQFPP9RPc+vb2HBtiaMgcfWNPK3DU28vKHJ fn4d8M2YXROONMul/vYeaG2f2WhTA2qad7G1ciGTh/wWX8a487bb+eF1/4eduys4rvt59C87mdWf P/fffvfQiW7evJm7777bXooD687/ICZ31FtCXcJZbaEZ3TGJj52e0oKsiEGjhWFESZLBHZLWA2lj e9UmJBIOQLlOvRAIqVDCCu0ZoUkpj3kVDYRjf8JItNCUJzy0kLQo2Nms0EJaNnxhjz+xZx6W8Nil 5MY1kjwflCZufM7tnufOxTlIYMd+WzjXEhQextGGGaMca3hWXRD7IArhNJpcwyEsdgnPOSIXnHhC oKVHPHSOOuNINjQEeEbjC0eEIg35XpC5XmCHpr6uaYGWlkMhxNmeMf4aRo44n337620jzUXX2sCj f/0bQ4aezSOPvRI12X5198Pc8esH6dG9jOuvuYi+fXsyYGAfJk4YTSI3wWVTfs6jD7+KccgAixSw H3VvZTW33/EAQ0ZO4qhvfY+Bo85lyMhJ3PGr6dTW1WOA+x94iaMHn8WKVRvtHxnbPNMYTptwI6d9 50rCAUljJNPueYSBQ89h6HEXMWTIufz7vX+1yp1St/3sJu3uW+jsFD5QkJQo4SJiEdhavhQERkdd f7RBGY/H/97Mkk8awTUStYwTjlXWNGsqGhTVTcqKcUeNJfsZpCaCEhFNx1lge2WjlXD2TMDI8lyE MdEgxdCuCeuwv2aH316vLFiZc5jhlJdxjPlGgK2ZpDGk+HvFm0w8+g7iJBHCcM899/DEM0/RvVtX jDF8q+vZ+LEidjds+cJ7fZWjvP/++7n11ltdRvaPGan6takAJSTSKBQCX/iU57n0R1ipki37Wvnb py02ovS0k2MGIzUoR+8nJVf1K6Q4ZrlDtdBIZaMSKX0e29xISms+aWilKe0DYWfXQmBO6JqLRLA/ bWxH0njRaGdhMk6XHHvC4WywJCs1c8w1/TrEiBGnVbQABk8naNQBzYEhJybxtbZUdMYiRn2cI5QZ nGZIxGs0YNL4JgYihjAtBMYyahkMUhuUsPXCtIQWE/BWRQspE1DdLFhV2YwKJSWEQCpFz4JE5r2E sUX9r+tUpcDHLSJho6qzJ4xl2n88wot/W8AVl57lrpudVHv66VdpaElzzlknWakZAYMH9AU0efn5 /OInVwDQpVMx3xpxNC1Nabbt3suguppM99/VPFd/tI7Lp/4LVTX1DBvanwvPP4NUKsXCpSt4+K8v YqTgX2+/nlQqRW1DKypodSm1reNKDPv31yKNxCcOaB5+5GXuu38GPXt15YrxpzBv0Wr+8Oenyc/P 5YZrJxJdMA041n2j3fy4O78TjsxlzseNGGmzIw/nVIRtZkqjnVaYzc6eWKvp3iFB32I7XKJRNKcE t75RS4BH90KPfx2bByLm3sM5z7B8bHB11OiWULHfFo2NSFFe6FHTalDGEEfRKU8gQvkQL/sByDQM jXFwvAixcXA72O8y6be7806Yz4gYu6pWcsqRlzhu1zTgMXLkMYwaNYKQEEYrGNHlO+ypXUcQBPi+ 3+bYX9Vw+qoO/4Fk4oej0/VBElMK5cURRhGYgNx4+EE90NCoDJv2t2B357DznUFSKmGVEK3Ojocn BFL7BCGTvIY1NY1IHQcBkhSKsO7mM7FHIV0TARBHkyZNOOaoSJsgIq4l/NeAcIkXZGb3hYG0FyCV b6uFTnFAO0hQKLgnscMIAcI1EHDV1LaEz0LYz2brngknS2E7LVbJ0VZThVE0pAzP79iP0QKprTia RCNkDKVa0TLOsV3zokjGwDcK7I8o6fC4YPIZ3POnx5jx3ByuuPicKIJa/eEWNm7ZwfgJJ9OpUymL F6/i1dnvMG3aT+x54ZpKbkDDAMncGIveeoSPN37C1Gvv4Je3XE3//j3YW1PL5VPvpL6+gel/vo1z zjyZEKpuuJ6ZM+ewaetOIKxLZoPxM80Uz0CAco01n1feWoIQ8OqMP9KxUzE3/3gK0373KJMnjY+e AWNU22vnpnYsw5jh7H4J5m5sAmO76Za20EWSSLSD3XlGO8cV46EV9UwbX4Iwdq4/0JLAPQs9iu2m CmSIl8NIO8vh2efIclZUNmqkTqM9Sfdiw2c1ds0o4dMxzwekrWfqEMpnKQItwsBzJZFMyyrDtfv/ 1j237PlxQvhct47DMVoQ4mYJSUy0cnVz7fapGPmJXpEzzXaAX/X+2bC5gznQg0O8Dh/zQwiJweo4 GenRnBbk+I6+zPgRCbHR8ehrrTS+lFZeRNrdtzBu66wYiRZWUlYa0Eag7CA/0kjSQhBHckSuz4Qj kgwvTVo+VA8K/TgxI1BS4WGhSLUpTWNKkxfH7urSkpF4IY5Pg5CSyhYwgcqMuxpB0hMkvcw8dlQF MyrDXm8MlvnGJ0DjG4UlzLaLUbhI9MBdVQttmctN3BH3KiRWrjgtQWofoS2Ua3AHjxNK4xaWpjTC O0iX5WtYNiFL187FjB1zPG+/vYyPNm3mqAF98ITPc8/NxhjDlMlngTHEc+J0LCtxUZbFZmZPNhnn Ij00G9ZvY84b7/G9s8bRt393/vLg81TW1nHXHddzzpljbEPKpeXCSC68YAL1+xsB2iwkyII3GcD4 CJlpphTl+wgNq9eu5zvjjicR87n91usQoZqtaHvdXIMf6ZycNJpYzOf644t4YFk9HXIMJXkJ8nzr VPelDFWNiuaUAWnlwLVJU9UMz/x9P50LE2iTYk+9cPdc0dCseXNbC1IrTuubh0SwvbqFD6ugpsEg haZjnuSEI5MUJy0LfmWTXUtGexTHBMvqUyCTmKCZbnlxXE+Oxduq2FPTwL5mQ5eiJGcO74ZxqA1j Mo4nGn5wzuzTTz9l5cqVNDU10aNHD0444QSWLFnCp59+yoQJEygrK3OQrTjz589j0KDBdOnSBa08 pAezZr1Ijx49GTlyJDU1tSxYsICJEyeGxSgef/xJDD4/uPyS6P3tc2ZoaWlh0aJFVFRUUFRUxKhR oygvL29znysrK1m2bBme5zF+/Hg8z/uCUz0cTXaKe2h8PE1UK9yyL2Vrm04K2RhJWhkUikBrB6mJ oVD4UuPhURYDT4SkvcrCYaRl2fd8Q3HCd91whdSgSHNxn0KOKU1iDBipEGiSXkBBzDZ+lKu7Gh3j /aoW7K5uSxGRM1WaQNoR0GWVDRbKJISl2ZMeXXJj+No2URJeGOHYNLxVaVvIFwa0b6M0Nza4P21r oNK4GqhJR82HzIOhMCJhSxxauxKmTyAUvg4QWpAbM5x5RJIbBxTb+E0b50y/Odb3jDN1ztkIplx0 JsYYnn3uDaRQNDa38NKrS+jevTMnnzwcYQRDh/Tj5lumYsdNsf+THe2GjSvB+RPHMful+xnYryfS eLz1xlIKC3KYcsn3MhjMsOnk9pzCgpzofDDyC05BCNB+gE+GuOWm639AMsfj8qvu4MLLbuXtJR84 sIIH2nN8nKGYosby6obNHWnLHjrFMV1jTPtuKb8bX8Ktp+TzoxPzuemkAu44rZB7vtuRW8eWcvHQ HHqWePjSDm8s2NLCMx/sZ8YHrbyzLYVBooTPh3uaeWFNI8981Epjs+K+pfv5zeImZq1v5N3tTSza kebFjxq57a1aqhst5rayIY0SksKkPfcd1WmMSePHE3QptIMmD7+zkVueWcO9czbw4KKtFOZ4tr4r PTsM8CXkMzNnzuSUU06hsbERKSXPPPMM27dvZ8uWLUydOpXHHnssK6KFyy67jMefeMRlCopUKuCS Sy6nrq4OgCuvvJqbb745qr3+4Q9/5Morp7Jh/QcsWLCAhQsX0tLSgjGG+fPnM2DAAJYsWYLWmuXL lzNz5kz3HNr1MX36dCZPnszUqVM566yzuPnmm7Oeq0ykfTia36dDjIrmlHVAJg3SY/7eJoaUhjg9 wzEdEjx0ckfQFoIzc1sTb+3cD8ZHS9vp7laYiDqxAstso3UaKeOkTAvXHNmB+7fUIVRY9/J4YGMV tw3uSGHClgq00Ujhc1SJx/K9rSgds2mc0Lz8eQODS+KUJrHEIuHDJgS+9tnRrHjzs0aE8EmbtKt1 wtFFtusuMCTajD0CUvBZY4qeBXEwAUb6VrHRaCpaIC1s6uVhI+A8P0bIBWkEeCH+UBjyfI+ze1je VT/mUSgVpYkkXXMCEjEnNex01yNNdJNxPl/H2o4aBoDH2NOOo2vXTjz/0jvc8YurefW1RTQ11PPD a8/HE5K6ffUMH3EBc1+7nwED+7hbF6bOLi2LwPj2qv3gql/Q0JRiy/q/sWt3Nf379cDzD5jSyoKV ZaMs24zGRj91r9PO4SIYNWoQc197mGn3PMLcuYtYsOh9Rp84nPv/dCudS4vDYmjU9DdCZqBM7j2V jOGjKc3J1pW1XxsDcQ96F0t6F8UZ2yvO33cHPPSB3ZR75dlSUHVDwP5UGs/49CxK4PmGXiUxPA92 7NPkxSRXHJNDab7k46qAmWsVzWnN6xsbuWx4PpXN9l3LiyXawGf7Nfm+T5/OOeT6kulvb+CRJdvw NHQpLeChqaMoLcixPLPGYESGhxXaZke33XYb5513HlOmTEEIwSWX2CiyvLycn/3sZ7z00kv8/Oc/ xxjDu+8uZufO3cx47kV+9tNfIoTHokXzKCkpZsyYk7FIgFDkL2Dt2g1s3LgZpQybNm0hJ2cBAMOG DWPXrl2ce+653HXXXfzTP/3Tlz6P1113HTfccAMNDQ2MHDmSZ599lvvuu4/sSboDBRoPF5Mnd7TN AI1dmMJI1tUGLNnTQjSSJwRSe0gEzYHkvepWuzBk2PXTHFPiO2hOgNZEu6t20JCjinM4tVOhbTQJ gScU9c3w4NYGi1sN0z4MY7vko4W0cse4tCsw/O7v9fy9rjVaOBhDIGFNdTN/+LCOtJEIo5DC1naN VJzcLR+rIe5TmpsRqJPGjmO/XdFiF1o4jYji3apWUoGlKQuRDkkpSXoiakLgyGI09jg50jCuLM64 8gSnlfmM6JigZ6EkEYtjYV52ZBZARdjFb/Zm2maGo50jYPLkM9jfUMecN5bw9IzXEV6MCyZ/F22g uLiQuW9Mp1//3jZSDGFlTqlThNLI2ABeGsPNN13KLTddji88Cgtz2bO32sJxREYWhDCdCyN73AHc z75wztq32NSQb8BAn56defiBf2Hp4ic496xTWPbuWm66+d8dnaQdZLAblGV/sDV1+xmEUVkMCZrs 8VmBpZeLgCvCwyAZ2jXO5m3rKPZS/HJMAbeNyadvqR1NkV7AbePyufXUYiYPzSXPl9w3oYA/nlnI sG4xuhf4nN47QYdcH98Y9qckzYGgNa2QOk2PAjtp1ahyaWjVtNbt4cF3PubBBZ/gyQR9u3fkiatP oGNu0o4xOETCgfP42Y4nkUjw6KOPMnv27OizGWPIzc1l4sSJrFixgp07dyKEYMaMGYwcOZI1a9aw des2AF5/fTaXXnopvh8HMuUWYwRDhw7luuuuQQjBued+nzvvvJM777yT4uJifv/739Pa2sqVV175 lc9h6DTz8/MZN24clZWVB31WDzdnCiB7FyboX5RjoUX4CG2QaJ7cWs3MHY3UtKYxAgJj2NIYcNf6 GppaA7T0kI4YojQmOb5Tnkv5fDzfduqNFLZBZWIEQjPxyFwK4naUUwuJ9n221DTx/KdNBCbT4exZ EGdEhwTS2MXgCYHSUG00929o5NY1e3lwYz0PbdrPrSuq+fOmBhpU4Jy1wWhBIBSndi6iYzxk8hQM KHLYQrcRGKVZuaeZ+9fXsaIyzcrqZmZua+SZTfvtQhXalg+M4egiG0HbCMxllkiLeXW1R+GF82EW txnBE43daKzDUS7Zz56S/vqmHGlvmA5LKZly4QQwHvf86UlWvv8RZ4w7ka6dSlxhQJNOK16fuzhr Ysc6/qgcYWcnAfjo482s//hTLrpgLEakGX3SMPburWHx4lUYwkUZznO7yNt9wJwcO4G3b1+D/V0W Sj/V3OJ4FQBpqKyuo7qmHoAju3Zl+p/+mV59OrN48aoM9lj6tr4dnWnaHU24xqP97qEFW3hh5aes 372PppRCaRkNcwg0rUqzfMteJt73Dnt37UTu227/1Cj2pXKIxRKUJn3bwTe2mRloxYJtKe57t4mr Z9Vx1aw6rnyxhn2NmoAYRxZJ9jWl0V6SnLx8enTIoVXBx9s3sv6j93hq3ns8uHA7sZhH9+IYT159 LIUJv62ahLEb+ZfVGqdNm0ZzczPnnHMOp5xyCqtXr46c2KWXXgrAyy+/jNaauXPn8cgjjyCE4IUX XsIYxZw5b3DFFVdE1wlcMOWGQkIzRrVx2MuXL6esrIxEIvGFczrQQYZfl5WVtXnNgZwPh5v5oLmi fyH/8kEN6SCF8iSekUjhMf/zVuZ/3ooXCxDEaQlarRCfBB8PJQyeMVzWvyiaxkFLlDF42DqQnZ9X eEiSMbi4TxEPrq934WCaQCje3NVMrwKPUSV2l8YopvQuYEejpqolwNOGuGfQQYBGUt1sqGpqwEgP T4MfrnsToKVN0bvmJji/Zy5aWFJnYQyjOubx8qctNAZpu/AcyP7D2mY+rG1FS88KOnphO8Z2gT1h GNO9AOE0eYQIIWXY6EhY9VAMGQVUFTZebOpmwtFK4xA/ggiy9bVNZ1KosGOMUXTpXMa4Md9i3qIV SA8uuOCMrI60ZM3q9cxftJyzzjwlOpdQdyp8jWXtF8xfsIqnn32NCWOP47TTT+DGay5m1qvz+T8/ +R0vPncPfXsfSYjDREvWb9jMO+++zw1XXUTPXkdgUKxcsYYJ40+ITnvr1k+ora5j9JARYAxvL1jF pVf+gmuuuoBf/fJajNAEgaa1BfJzc5CR/LZw3XA3viti0XlLbOf8+idW8P6n+8DNuOcnfDoVJMmL 2/veGghqGprY15AmLWyDbnTfTmgNDYFh5YYN5BeV0a9nkZNOFtS2wN0LGqhu0aAV3TrkU5YnQKVY W6lJxD2OKM1hXyqFLxRVe2vodExHtu8J2P3JJmQixoSRfVj7WT1VTU3saw6orG+hY2FOdM2toINA SIuhOdCMMUyYMIF169Zx2223MWPGDEaPHs2yZcsYNmwYp556Kt26deOll15i6NChjBx5DMOGDePY Y4/l2WefZvLkSZSWltK/f3+iwQ77zmgd4HmxNo2w7K8bGhpIp9MHTdfDuuh/FXUenPPh8DEJkpKE 4KajSvA9iWdAGQFaoGSAEmlUSpAKbPPAE8Li8Rzb/SW9CxlYFI8mqrRUSG1sU8s1n8JoAmMYVZJk aGnSTlCBTYVJ8/i2Rva0ZBxMfkJwy+ASynI8jAgItEQ65iclfISIEcqcBNpGJ7Z5FKdrfowfDS4g IRwnkBYYIcn3BFP7FCEEeFoSTpRo4Ry/toQu2thjedpSDo7rmk//QptI2vdQrryhUUagUJYqzjlh jCLkHRHCi/CKIrzibb/4Bu6ii5qFQBDqVcUQAqZcOgGArmWdOP3UY91tUAhtuOzSs/nr9F8zb9F7 fLL9c3c/PLeq7RJPBYoHH36RM79zEkvffpyx405AAAMH9mTab39Kbe1+Tj/nBm779QPMeXMxr7y2 gFtu/T3f/d4P2bu7BiE0p512HH17ljP9ry/y09v+wNx5y3j4iZf5/uSfYoTm6qnnIRAcf/zRlJWW 8Nijs/j9fzzFa3MXc9nVd7B79x4mThxPOAxihQbDxp4bmc1S5pz+zmZW7aiNomVjDA2tAdsqG1lf 0cSHn9WxuaKO6sYWLCukpDiZ4NvHdEVKzaeV+9m2ZTPr162mfu9OOzyBYMaHTVQ3gy9j/HJMCXee FueHx8a5fGQhSqWpr6slKVNsrqhj/brVbN60lm4lOWytbCRRUITvxfnJmUO4dmx/PGXY1xRw49PL CfGiWbcTy3T/xcZN6IT69OnDs88+y6xZs2hubub111+Pfn/xxRezaNEiHn74YSZNmgTApEmTWLt2 Lffeey9Tp04N3yk6bjajVxg5KpVRKQDo27cvlZWVLF++vI0zPJC28cvscHSgB5oNsoygT4HHvw3v wMCiXIS0zSkndIDyBJLARnVuIqhjPMZNg0o4uWsOCKtbo1FI4zlpBY3nh1g3A0a7lBem9M0lKUGo gJABqiVQPLCplhZtiQMNkk5JuH1YKSeX5RATEEgrvuC5UgDCQxlBzPNAWBjX6d2T/GxoCcWxGFpa 6JMWoRCJYlhpjB8NKqQ46aG1tlzPWmTG9kJWf6HxfDi/Rx7n9863Pwt/JQQYjwCBkDYal8ZGMfZ1 npusaftA/k/YuNNOokvHDkyefAa+n0nvQmduJPzrrx/iiefm0NKa5sO1WzASdu2tZv2HW/h44w7+ 7bd/4cUX59Grdzd7UHcdLr3gdJ55ahr9eh3BY4/OYuo1v+LaH97Fc8/NZcjggZz/vW8DkkTM46kn 7uHYY4bw1DOz+cE1d3L7HfejleLPv/8FY8ccCwJykzk88vAdlHUuZtp9j3P1Db9h4YL3+O4Zp3L7 P0+1G5lUUQPKAupt2cXPWsdLt+0FJFJb6J8vZVTm0GTgZWFTsVuBx0NXjcYTtim3szZFMr8AITzm fbiVx5du5cUVn/D0W0v5+OMP2LxxLQQpUi2KpZsrufyh5WzasJZNGz8kl1bWfV5Na8M+vFiMHN+w eVedHcsGEh6cO6IbwnNELpUpZq3Yjt2cbd0+u5F2oBljaGhoiL4fNGgQUkoXcdpn86KLLkIpxcsv v8yECXZDnTx5MkIInnzySSZNmnRAam/aYEtLSkoA2LBhQ5vX3XjjjUgpueSSS1i0aFHUqTfGEAQH H6M90Ikejml+tvmGNELEUECHZJwfD46zrTHJst2NbGuKUdMc0JAK0NKnxDf06JBgRMck3yr18R32 T+OmgbCCb+O65TKiRCFFzLW7IC5Cso00BTHJ9UcV8XmjslK2wvppH6hrlXROGsux52livseUvsV8 p1yxvLKR9fUee5rt9JMwkpyYpkeeZFCHDhzfMUl+wuCjHGBbYITTFXcExaAZlJ/D3aNyWVHbwtba FDsaFPuUh1atFMQkXfJyGZArGdE5Qb4fwqM8hAjTMMH5vfJIGUNISJL0LFGHhaZgF/ghsCP7nmbK xWdz4QXfJuOJMiaAd17/T3x8Hp/xMr/85/tYtuhZ7p72EK/PX8GOda/y6it/ZmDvPtEfREgHDKOP H8Ibs//Cju072b6tAqVT9B/QmyOOKHPcAhYP3LO8jL+9cB+bt+5g67YKigrijBp+FH5OMoMEQDBq yGDefeevrFy9kYbaffQe0Iu+vbph67K2ERi+3gBknUsogHNin85s/nyLwyt7URPKRrjGAv210woT kvy8JD2KHHBfePTplIMkQHo+rYHH/W9tAU8y6bjuPL1kIw1Ivn/fG66WKAmClK21ez6xWIzF63ci 4nnkxq2u2pwP99gNGruPCW24+tQ+/OeCrQijuWvuJgaUF3J0txIbexhtSWqyyW6yIEfDhg1j4MCB 9O7dm/nz53Pttdfy/e9/P7qnI0aMYNCgQQwfPpxk0ioJl5eXM3r0aHr27ElhYaG9fs655efnk5eX F/19eXk5I0aM4N577+WFF17gvPPO45ZbbmH8+PE8+uij3HTTTYwZM4acnBzKy8u5/vrr+dGPfkRu bi5FRUVtnq9EIkFRUVGbEsHhTO0nTHhVwwdNeAit7A1VxlHyKddkcdpQDgsojAiVZu3DrYNIYdSO Z1oQfkhlFrHjawhkGl/7VmsJ44TzJCacpYeMfLTJlAKyMaCEVHAQUcYZJOgAJT03WootQxhLLGxZ 4d0xtcgQtzu5FIOIVBmjBooWWefuRk6FQmrfjpKGD76y3GnCkWkHnrGcCF/Dvq7qKWhSaUM8Firb un54yDtqsAqXCJpbAj5Yu5ETjj2a7Tt28tmuak4+YXCEHAivfwhbsl11191HRmD1zFx7ZtFok3LS GT5NLc0E6RCn6rhStYeWUF1VS6eOJVmnb59LIp7PtvwL4XsaFNIINJKWllbG/WEpQVqBCdqci0QT KhkE4USSUYzu25l7Lx7lnDIs2ribl1bvoaq+kbjwObFfGVeN7c0TSzcAywqhAAAIpUlEQVSzYFMl dQ2KroUJbji9HzUNKd5Yu5eyohhXnNKXB+Z9zP4WzVHdi7nkhHJ+8+oGGtOaTgUxfvztgRhjUEJw x/NrSKk4LekGThnYmUmjumNEzJWNAhDxL+2GV1RUUFtbS3l5OQUFBdG9CV/b1NSE53ltGkjNzc1I KYnHbXf/q1JwpRQVFRXk5ORQUlLS5tipVIqtW7cSi8Xo06fPF9L/A6ekDvzd4WzCmLQJ8Z8Wq+d0 48O6jrGUdaAQJua8j8MnhgtHC6dECpispEXY2qIWChERF2elwsICmTXCIgZkgHFIg3A+PwQPRpLH ziIuToOdztIWnmJ1xWOZ8qS2dVYlPHwXzdjFHWIunaMR4oDoTTsokQQVIL2Yg1BZZyJUgPEyAJ1Q Cyty/HwjENOvLyNtrPMnwu66TSLCwLp7oshMb2mBkYGrb4e0f2nbXHOLYsene2hpaaF+XwM9e/Vg 08YtxJIJmptbGdCvBxs+2k5hUQ6FRUUE6TSJRIx0oPl8116KO+Syb18jfixBp5J8qmrqqdxbQ/3+ RmJxj0FH9aVTaTG79lYhlaGsaxk1lXUMH97fwrOcP7XPib33CGEJc6TBx/DRzn2s3FaD59nSjjbQ 1JKiIaXZu6+FrZX7qdjfilAaJSSCgAemHMeoXqVAqAAcbhQOExqOkFmMGFo4mJOr0wpDZuONrn+o l2VcOi+zNhwclEy5kplx9WHxjTQtv8q5/Xf+TmtNbW0tn3zyCRUVFfi+z/jx4zHGMGfOHCZMmNAm 2gynqN59913GjRsXHe+VV17h7LPPbrMpH66O1QcfaQxpjOU/VF4WhEOCtGLNMWIY7TBybjGGoOpQ 2RAEIuRcNGCMb1VN8TK4VIzr0IbRn7SLQnhoNxBgpJ3/N0KhhMQ3FpenNHgoG/9KHzR4UgOeq63Z CSvpuu0YS/CrEBhSgMPdibhzxJYPQAgX+diRLXeeIKWdf1aejzAGZIBQMcc65blztIvMdvftTLRt EnnfnFf9GmYXRqjUmR0xBtEmqlFIL0tFQOLgU4HbEJ3kr3Nghhi3/OJerr7yfN56ZyXVlXvZvaua RDzO0GH9eG3OEpKxOJW1dXy2u4K4iHHEEWU0NjXRrXsXVFrT0hyQVxhn+JD+/GX6TE4f+y0K8vJZ s3YrCxevobGxEaUUvu9TVFTAqFGDGT68byQQp01Y7/ajjdiz3TiM0RzdrZDB3TtkfKBrGRoduMam x87Kauauq+eJRRtJC8HbG/YyqleHqIRl1Wutw5VYHSiNRno2DAihZmApEz0hQAcg/cjRhMgHYYRb LxorXulwugLCKTIPhTGeA/YLrDqtvS/Zjiszuntwx9T2vfmCU/2ylFtrzerVqxk2bBirVq3i8ccf 58YbbySZTPL+++8zYcIEpk+fTn5+Pv369aO6uppFixYxZswY3nvvPYYOHUpeXh6rVq1i9uzZ3Hjj jaxbt463336bc845p80zebjO9EdXNSYs9Z7jELa4VGkjSZuEGMe4bkH4JsIuut3culaMpyK971An KmLRd2mZUTKD0ZREMrdW3xv7bq4T7jvHaozCw1KgSWkTaS90EmGkCVhyX+sclSsJ+FoQwwc3D27T XIM0tmMc3mDb8BWE1INga2o+CiEUQvvOabq0UTjyF7Cck8ZK50b874fIsxLqRoWfHWTWgrKMYhkI TRiZgzG2MSlwmEjpUATGDgbU7KmiYufndOncidy8JKWlRXQv74xSaY44siMdS4tICI/cXI9Nm3Yg 8Sjv3hGJorAowaaN25n39lK6du1Ap7Jidu/eSzwu2V/fTFFxLslEjE4lBRx9dD/efuu9CLlrlEYK 7HgmQATlD9y98YgUGMDCytyWL6V9an2jOKJTMdee2osnrjsRYwQqnbLXBusY7bCBbWiFzlNGaAL7 3Gl3SX0TIMg4OimtE9cIUBaDLFx5I8CS9yAyU2Uu1LDPb0jCLTKRn6XG1Fn38+B2YIPpQMd14O8P fE5mz55NY2Mj7733Hp07dyY/P5/3338fgNdee41EIsHo0aN5/fXX+eMf/0h9fT0LFy7k+eefJ5lM IoQgHo9z5JFHsmnTJkpKSigtLf3Ce2VDsg4nszgJ6frqoea8sA0Coe3YoREhD2lWvRCI5HKFJtS4 EMY+ckJo564dA5HSCC9mde+lY9XRwqZvWiA9u2DtcWWmViZAaJtKazeOF0YdYYRrLDGle0B98DQY ga+lCzhN5ljug0t7YLKBzdkWlhMwNhoWgJZpF51LwjpiqKBpg3mHXzXmkHGmOIWAKL0XTvLaRUt2 M8R+JnvxrUihsXVpLTxLtO1STytZ4jH9gdvxEVx40VkIgSM9TCMIMaFe9L9xeNGwVo0I5U3c9XfY XO24bw9MdY1R3HDV+fZ2CBCeLUFkMh1JiEmVIWdq1oiwLUvZl2WidR1FE73LCvnJGQPpU1ZA6NiE 9B2KwDW7jLYZlLuOAks+LU3aiTJm1E1DmZeI4NqLu9KWQeDjuWsQfn5hXHhibL04EB6+dpmcyER0 /1Uj52CMVAc6rf/KiXXu3JkZM2aQSCSoqqpi165dJBIJEokEQgiKioqYN28eOTk5dO7cmbq6Ok46 6SSqqqpYuHAhp59+OolEgnXr1jFgwABmzZp12DagDmaZplS7HZLW/4IH2DTzhjY1uNC1RR3Bdmu3 djsk7B9n6/hfaqEsi9P7JmRlMt/kYEC7tVu7fSPWHqEe8pYFEwpT4TCdNeoLpYp2a7d2+5+z9gj1 kDfXeNG2JaxR6LC5dBgW9dut3f43W3uEeqibAQingcg0ctoQW7Rbu7XboWDtK/IQN6uqaeFpFjVj +RRCbtV2a7d2O3Ss3aEe4mbha3YKyJM6A4MKRzbbrd3a7ZCxdod6iJsGtLQzZMa4oQMt0A503m7t 1m6HjrXXUNut3dqt3b4haw9x2q3d2q3dviFrd6jt1m7t1m7fkP1fw2PtSi8oWcAAAAAASUVORK5C YII= ------_=_NextPart_c07ed87f-3415-4257-a3a1-89f4081b9f11-- From nobody Mon Jun 11 15:05: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 749F7130ED4 for ; Mon, 11 Jun 2018 15:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdkM4977MitH for ; Mon, 11 Jun 2018 15:05:17 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [198.64.6.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4572127598 for ; Mon, 11 Jun 2018 15:05:17 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fSUw8-000Egn-AD (job@us.ntt.net) for v6ops@ietf.org; Mon, 11 Jun 2018 22:05:17 +0000 Received: by mail-ot0-f174.google.com with SMTP id r18-v6so11230245otk.1 for ; Mon, 11 Jun 2018 15:05:16 -0700 (PDT) X-Gm-Message-State: APt69E0wtF9MgQxGd7IeC8/YBvI0BrLIlTEU3nlmMfgEvM+OSg+Xs6+X LvhuZX4i/flLKaamfeFq2oxPOgWhWCPwjT2jldQNyA== X-Google-Smtp-Source: ADUXVKI/QFCG/FRdZTRi5F8WXnQGBru8n06MUx9rXyFbVudnE/0LBf/VX0vd5ePHXJOOfEG4qY7paxWiaR0A29HkLWQ= X-Received: by 2002:a9d:128f:: with SMTP id g15-v6mr644720otg.5.1528754716020; Mon, 11 Jun 2018 15:05:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:bd90:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 15:05:15 -0700 (PDT) X-Originating-IP: [192.147.168.22] In-Reply-To: References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> From: Job Snijders Date: Mon, 11 Jun 2018 22:05:15 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Simon Allard Cc: "v6ops@ietf.org" , "fredbaker.ietf@gmail.com" , "intarea-chairs@ietf.org" , draft-patterson-intarea-ipoe-health@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc244a056e64f1bf" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 22:05:20 -0000 --000000000000cc244a056e64f1bf Content-Type: text/plain; charset="UTF-8" I agree there is an issue, multiple access providers confirmed they are making (never great) trade-offs between the lease periods and potential downtime for customers. I think the proposed solution is interesting in that it seems quite manageable to retrofit this in existing deployments through a software update and avoiding the introduction of new protocols. This may not be the approach with the most technical elegance and sophistication, but is perhaps "just good enough" for the problem at hand. IETF yearns for feedback from operators, and this draft is exactly that. I encourage the authors to produce running code and run some trials to validate the idea. It'll be hard to argue with proven ideas :-) Kind regards, Job --000000000000cc244a056e64f1bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree there is an issue, mult= iple access providers confirmed they are making (never great) trade-offs be= tween the lease periods and potential downtime for customers.

I think the propose= d solution is interesting in that it seems quite manageable to retrofit thi= s in existing deployments through a software update and avoiding the introd= uction of new protocols. This may not be the approach with the most technic= al elegance and sophistication, but is perhaps "just good enough"= for the problem at hand. IETF yearns for feedback from operators, and this= draft is exactly that.

I encourage the authors to produce running code and run s= ome trials to validate the idea. It'll be hard to argue with proven ide= as :-)

Kind regards,

Job
--000000000000cc244a056e64f1bf-- From nobody Mon Jun 11 15:54: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 DBFA612F1A5; Mon, 11 Jun 2018 15:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 d5X0mrDN46jD; Mon, 11 Jun 2018 15:54:07 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241CD1274D0; Mon, 11 Jun 2018 15:54:07 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id l15-v6so12730461wmc.1; Mon, 11 Jun 2018 15:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1/UyozM9VLYGsweoOELkLYRYX3grvMtZWFU13jWtTB8=; b=M4Ps0JCQ1Io8qVUv847PiYpS+CWAlYfQyIWD+X1Mwf1ZgkXi47YZQ/QyPR8j9uIJ5Q 2WmqL9uUOWKrej6vsYHmO8WuhfikpnlZD+zwwmVVGUApKTPZpfB57eTOHFzEf8bQkPge x9LxD1dvXOmzizXUHkcfN8AA6c81G7eeibkGS7hqr3LVRJYUcFEZ4pI3SZ3xvWbn0v8p n/G+YH7KXqmxSp10PyR6bJ0gWy7tswMbXbdznVzxD5cg8SOk2QGnso4MwN/ubaDJjVD5 LCtge7pnIgYZba4Lv1eR4i519VXNkzcjBv8AapNeF5lP1G8fRjDSWA58KJDF5P6xsVVd ErWw== 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=1/UyozM9VLYGsweoOELkLYRYX3grvMtZWFU13jWtTB8=; b=GsE7mrqtkonsJe7uknljc7VZH5tL6+2cWHRIA8Srg14tCZjYAwyYf3cDrbW7AFndac zGQR8ZgCAwpu2sHrdKcsNoCWcFKH9hV5wISajZiEZBNvk8V0FyY1wVWKQV3RoXWIr+SR KA2cFKSEqvY0Lsc/UMRbivLkPxLv0kN3awcFkHSo82c6EkvOuEhk2nc+kwna+fg7ivXN KFYI9sY+6x4qy4TkofEYpvmF720fpo8tAGTGB9w9FQtGeBjau+MOww8GO1KdSmK54iev i8OCwDcFbEFtrFuTg422Nxw/qdqQVZ99jK8b66FJD/EHpAyLt0SVwgRt9k2n7U4YxROO Rt6g== X-Gm-Message-State: APt69E1MewKwtIeC3eLF08I0noEKIkiYV3DB4vy19hTSywyVdo5lyRrS DnuY6iZ1EeDbKuL2QxQtAFi9Z0UB X-Google-Smtp-Source: ADUXVKL6VivxVRhH3lfH/XaWzuTc5k/mZRfzSN1pNpdPYYy0o40ZKK5xsxGZQD6tk7Lr54nmFQAqEQ== X-Received: by 2002:a50:ac84:: with SMTP id x4-v6mr949859edc.152.1528757645730; Mon, 11 Jun 2018 15:54:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::11bf? ([2600:8802:5600:1546::11bf]) by smtp.gmail.com with ESMTPSA id f2-v6sm19062181edq.28.2018.06.11.15.54.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 15:54:04 -0700 (PDT) From: Fred Baker Message-Id: <4DEB4487-DFD2-47E4-8120-D077036DAC07@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FB283517-6386-47E8-BE21-445E535B2EE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 11 Jun 2018 15:54:00 -0700 In-Reply-To: Cc: "v6ops@ietf.org" , int-area To: Simon Allard References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 22:54:10 -0000 --Apple-Mail=_FB283517-6386-47E8-BE21-445E535B2EE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Simon. This is being pursued in int-area, as it will require a = DHCP change. However, it is an operational issue, which is where v6ops = comes in. > On Jun 11, 2018, at 2:45 PM, Simon Allard = wrote: >=20 > Hi Fred >=20 > IPoE Health is something we have struggled with. We are a NZ based ISP = with a large IPoE customer base. >=20 > We are currently running our BNG's with 5 minute lease timers to try = and get around the issue where the BNG declares the subscriber as dead = and kills the session, however the client remains online until the lease = expires. >=20 > We have had discussions with our CPE vendors around arp = detection/resetting DHCP however those conversations have not gone well, = with the CPE vendor saying that ARP and DHCP are 2 different things and = can't be mixed. We also looked at doing something similar with DNS (3 = DNS request fail and it turns DHCP into discovery mode), and BFD but = nothing really got passed the whiteboard discussions phase. >=20 > If there was an accepted RFC we could point the vendors at, it would = make those discussions much easier. >=20 > Cheers, > Simon > AS9790 >=20 >=20 > Simon Allard=E2=80=8B | Development & Operations Manager > D: +64 9 550 2790 E: Simon.Allard@vocusgroup.co.nz > M: +64 20 1000 790 W: vocusgroup.co.nz > A: Level 2, 1-7 The Strand, Takapuna 0622 > >=20 > ---------- Forwarded message --------- > From: Fred Baker > Date: Sat, 9 Jun 2018 at 22:58 > Subject: [v6ops] draft-patterson-intarea-ipoe-health > To: > Cc: >=20 >=20 > Looking for comments on draft-patterson-intarea-ipoe-health-00. The = authors would like to discuss it in v6ops at IETF 102 (Montreal). Do = folks find it interesting/useful? >=20 > The primary working group for this will be intarea, for reasons = related to the charter. However, it would be useful to know that the = problem is a general one, and get comments on the proposed solution. >=20 > Sent from my iPad > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_FB283517-6386-47E8-BE21-445E535B2EE2 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+AFAlse/YkACgkQEhdRnd2G P+DrRw//XhxOjSuY1Nif3d3fHCjhn1BCUEP18BLuTQvXGS8eYcach2ECKMsnv3Ci /gXx7aTReDvMQ2W8pm/yiB5dM41g+SBYFqdxppyeyooypgatQdFQ18EhKqXUOfy4 61vzy/qM7mykBZuDHW8qUDEcRNEBuAJbG1NalLnKY6Wh7rGmgxkhjNzrJmx6zVkx JowapuLx/jRMkQAl5whl7aGU/J19Mn4SZPF+lFetUHwP+j1jOF5SWjD/HfPNzE7u elYkBTpzpB5UhubQZFCC4UsSscE5laYhqqxTRSVTF8HRfq9WsNMerpBvevB5iOXG WH8s7ucKfy4LBXu0r/LljIGUgbL5kD5frb8tgjPG/CfvH31IsD5zQNj3U6ild9cO Yfbj47Kq6ln1VUbBpehNFG7ACQMOPDFUVanFCXl18g2VuGs0Q/XOVAJvMX+8EyZh Bu0hm5y1Dh2zXQz3TQpfq90mhWTH18rkMErMM3a4ThBRRMhAclVkn9OsaV/d1ule JlntQXhBBLM0jUHNnhxeofQ2Ct5jhA/GXPcOPUk6elkgNewB8MO+X3fuMM+vOsxl tr+DNlGkEn1MyAfVQAN60HCSTMfmQNjR87vcwvVqmPrrE75Ow9xJlsUYM3ci0Om4 15852lzlaOqM7nmDTThJawmfbBkm1lNlbyvMc2cZONvj4VcAzeQ= =LhP7 -----END PGP SIGNATURE----- --Apple-Mail=_FB283517-6386-47E8-BE21-445E535B2EE2-- From nobody Mon Jun 11 15:55:44 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 69F5B130FF1; Mon, 11 Jun 2018 15:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8wTSRAa1h07; Mon, 11 Jun 2018 15:54:49 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BCF13108E; Mon, 11 Jun 2018 15:54:49 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id l15-v6so12731784wmc.1; Mon, 11 Jun 2018 15:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BgXmwT75QSDhja37tRw4jfNoAhoAkKGC3yuP6fvwCYI=; b=kgm6vU3OfVDgioyjHqvyWx5/TYPGF3PVvpLloHd50+RN0PXVu1EC4ZY5TefaRlSF1K fbrzxcM3Ef2GHXaEHnwCotPl122xf1hsnihC0w/Fk1RO+pK1kdtufWBHKx28aZyECI4o QtZgoja4si8TvVLRC0t9bMA5zgayknoWIdWayzZ1pw9gHB3kGxI/IRlgOkqcSS0wIkzu MkWXFzKTsWdh7DH7L/AtpQP6JKDjqH8ejg5cSRRl+yiMNlY4946+b4RzBBuv2HbOgR4+ Rnvd+drvcxwBQ1lJSW2fnqMa0/rQe5Z85pLIcCpBUmPt5V2ogZ925YSqMmMhBWf867EI kLxg== 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=BgXmwT75QSDhja37tRw4jfNoAhoAkKGC3yuP6fvwCYI=; b=CkXnB2hnf2aQyLA6o9Be5eZSMkxbs3IPy6m0LfO9xiY3B3c1B1qkG4tIftOOKZANjf eBbEAnSf5/f8B+oFDDXRhyTVv9HS8caGgixQ88JTRgElUGkmaPWvDi58mK7R+fFwGwov OfYn81dVMYFTr/itwJjrwAphPK+6WskkMqL51Q3QrpnlYu4o4so2uzgqhWMXgLvWh11e Hgnwbc7aKP4liOfGhCFg0qKyiTyqfedCT2/WZqC98fhzSuEvrhD8A8b2q8WlzsJBUtN0 lr645Qi/Z7M4xMiyaC99RebUegnFG+UEECv7cQzFxKMWnT8yD7WvKNb0R+v8KohF6uN+ Hd7w== X-Gm-Message-State: APt69E1XrQ0c8ao+sbACIR5u3ApI8q8BOTXz/GHXB8IRjulb1k8xkDQC 9qZN5TQfRUMcs1UeDMRz8tg= X-Google-Smtp-Source: ADUXVKI+tLPhuozBHXtFi+dLsjyWajJQwZxpdBlvn0sjKnv7d8FvAHc07+Qd+m1PGmi9Mv1SIv6GJg== X-Received: by 2002:a50:9248:: with SMTP id j8-v6mr961338eda.134.1528757688172; Mon, 11 Jun 2018 15:54:48 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::11bf? ([2600:8802:5600:1546::11bf]) by smtp.gmail.com with ESMTPSA id f2-v6sm19062181edq.28.2018.06.11.15.54.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 15:54:47 -0700 (PDT) From: Fred Baker Message-Id: <12D38046-513B-47DB-A6AC-971AF9E8160C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B81A3081-5742-4F93-980C-803AE7ACA4E5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 11 Jun 2018 15:54:44 -0700 In-Reply-To: Cc: Simon Allard , "v6ops@ietf.org" , int-area , draft-patterson-intarea-ipoe-health@ietf.org To: Job Snijders References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 22:55:01 -0000 --Apple-Mail=_B81A3081-5742-4F93-980C-803AE7ACA4E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, Job. This is being pursued in int-area, as it will require a = DHCP change. However, it is an operational issue, which is where v6ops = comes in. > On Jun 11, 2018, at 3:05 PM, Job Snijders wrote: >=20 > I agree there is an issue, multiple access providers confirmed they = are making (never great) trade-offs between the lease periods and = potential downtime for customers. >=20 > I think the proposed solution is interesting in that it seems quite = manageable to retrofit this in existing deployments through a software = update and avoiding the introduction of new protocols. This may not be = the approach with the most technical elegance and sophistication, but is = perhaps "just good enough" for the problem at hand. IETF yearns for = feedback from operators, and this draft is exactly that. >=20 > I encourage the authors to produce running code and run some trials to = validate the idea. It'll be hard to argue with proven ideas :-) >=20 > Kind regards, >=20 > Job --Apple-Mail=_B81A3081-5742-4F93-980C-803AE7ACA4E5 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+AFAlse/bUACgkQEhdRnd2G P+CZpQ//d7faCWLPU7G8bFrolK1C7JEdL2Yr1jJDy7a3E65LSIrTTifeSDHAqELd uP7k9klzwDwEs+mIBwm0d8TL809Zij/5C4AzcwlqCv3fde8Nwjq9D/IEmaPK2Hss X+I3ae3v3KnNZ8jhh/CxIdkt8zyI3ch91dFn9nV7mqxjbaclnPPZqQJ1rShYzWnN haivDEpzVZutl+a+DmchRuCH1P21w1tkqj6IGlcUuLRWg8LZ9Yv4DOd7aQjPMMwQ 8ebYE8bIJk8JbyRsQwZmcapx1NRFJ/S0UUjJqcFLO++p5EoWaJWLVlVk8LwaywV1 zpBS2ktCU6GKUKMUw/P6tW21t86kLPKLWqwDUAeeR6IViIxLBtqzCits63tpyvsM fqryw14n+fZitRRPJBtQNus826q6tv09zq6WwGSUoA8AiKgUs814V4SBuu4zbkvP Kkoa3OTwMtvyFipk1ZVoXLJuxHBGMvVy7byt1bOfdEYT7yZMMT2sbntQ5ku1vf9y QNSq7/+wJ4mI56tQhXFh020sPuHzyWq8hQh2SUNX09/Hyun9SPx4bSKg83ZYxGMk 3qkNTHZhlZ9IT2JorFzFvHaKRNUe1i8MAqcZu+bNag9I4K8D4FTX0HTplGACR9KU nXfFFVsT1kmkL3QHkxH/dZFb7T/p7WXe7nkSfLEiPNn0WXSQj3A= =fNT8 -----END PGP SIGNATURE----- --Apple-Mail=_B81A3081-5742-4F93-980C-803AE7ACA4E5-- From nobody Mon Jun 11 17:39: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 77A4F130E7D for ; Mon, 11 Jun 2018 17:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 yXM0ZpjkbbDn for ; Mon, 11 Jun 2018 17:38:51 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB565130DEE for ; Mon, 11 Jun 2018 17:38:51 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5C0PRnI011222; Mon, 11 Jun 2018 20:38:43 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2jj2yxgtar-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jun 2018 20:38:43 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5C0cfRq023061; Mon, 11 Jun 2018 20:38:41 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5C0cdfS023021; Mon, 11 Jun 2018 20:38:39 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 703B540002D2; Tue, 12 Jun 2018 00:38:39 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30483.vci.att.com (Service) with ESMTPS id 55AA540002AD; Tue, 12 Jun 2018 00:38:39 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0399.000; Mon, 11 Jun 2018 20:38:39 -0400 From: "STARK, BARBARA H" To: "'Andrew Sullivan'" , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion Thread-Index: AQHT6yhW9lKFyPxHQkiH7TopwB0r96RHWaqAgAAIeoCAABOXAIAUe9MA Date: Tue, 12 Jun 2018 00:38:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDE6249@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> <20180529193736.GA8084@mx4.yitter.info> In-Reply-To: <20180529193736.GA8084@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.214.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120003 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:38:56 -0000 I've been rather quiet on this, trying to figure out how to politely say (w= ith explanation) that I don't think this doc is in a state that would make = it acceptable as a WG draft. But in re-reading Andrew's response from a few= weeks ago, I think he's managed to put into words what some of my reservat= ions are. I'm top-posting on Andrew's email, with my summary of some of the= points he made, and my conclusions. A BCP that provides accurate and usable criteria for evaluating "which NAT6= 4 architecture is right for me" might be a good thing to produce. But this = draft isn't it. This draft lacks WG consensus that it has the correct asses= sment of the various architectural options. It is also not written in a way= that makes it easy to compare the pros and cons of the various options aga= inst the needs of a network operator. The draft has potential, but isn't th= ere (yet?). I don't have enough interest in this to spend the time needed to overcome t= hese objections. So raising these objections should not be seen as an oblig= ation to actively provide the corrections needed to overcome these objectio= ns. Barbara > -----Original Message----- > From: v6ops On Behalf Of Andrew Sullivan > Sent: Tuesday, May 29, 2018 3:38 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion >=20 > Hi, >=20 > On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote: >=20 > > I understand your point that NAT64 was meant to be "imperfect", but thi= s > is something that is not valid for operators. Operators need to support > existing customers with existing devices and apps, that only have IPv4 > support, and this is only possible with NAT64 + CLAT. > > >=20 > Obviously, operators have customers and need to support whatever they > need to support. It appears that there are people who are using 464XLAT > with DNS64 where that works for them. I certainly have no trouble with > something that wants to outline (for instance) how one would make a > determination about whether anyone downstream is doing their own > validation. What I think is wrong here is a generic claim that one or an= other > approach is the only right answer, because the CLAT in many cases require= s > more translation (which means more overhead and more work that the > operator has to do). >=20 > > Also, most of the actual usages of 464XLAT are still using DNS64 (excep= t a > few like Orange in Poland if I recall correctly), so the point is to expl= ain that > you can also solve the DNSSEC issue, when using CLAT (not using DNS64), e= tc. > > >=20 > Well, you can indeed. I think there is nothing wrong with making this po= int, > but the document as it is appears to be suggesting that the trade-off is = not > clear in DNS64. I think RFC 6147 is crystal clear about it, so I don't g= et why this > document (which has a much less comprehensive treatment of what fails > and why) is an improvement. >=20 > > So, the goal of the document is to find what is the "best" possible > > way to deploy NAT64, which in my opinion, in the real world is by > > using it combined with CLAT. >=20 > I don't observe that the document is called "Jordi's opinion on best > NAT64 deployment scenarios". If the WG is supposed to work on this, then= I > think it would be better to outline the various trade-offs and allow peop= le to > make their own choices, fully informed. >=20 > > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I > > wanted to do the exercise of looking into all possible cases, just to > > make sure that somebody using the document see what is possible and > > what is not, instead of making the exercise by themselves. >=20 > I see. Such a section could be massively improved, then, by calling out = the > scenarios that are known not to work, that are broken on purpose, and so > on. At the moment, it reads as though these alternatives are all live > possibilities, but some of them simply aren't, were never intended to be,= and > are not a real problem anyone should have. >=20 > > What I disagree with you is in your comment that anyone who is willing = to > deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actuall= y not > needed in that case. > > >=20 > I think what I said is that they're going to _be able_ to, not that they = would. I > do not claim that DNS64 ought to be deployed by anyone. > It's just a mechanism that is available if it happens to fit a need, and = each > network operator needs to evaluate that. I claim that the I-D as written > doesn't actually help people do such an evaluation, and that in fact it l= eaves > out some of the necessary analysis. >=20 > > Maybe if you see the point that an operator will not be able to provide > services without the CLAT, you have a better understanding on the > document now. > > >=20 > It's simply false that an operator will not be able to provide service wi= thout > the CLAT, but it is true that _some_ operators will find such a service > inadequate. I believe that's why 464XLAT was invented, in fact. >=20 > > Would you agree that if an operator deploying IPv6-only access want to > make sure that the customers using some IPv4-only devices work fine, the > only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work? > > >=20 > No. But I believe that there are operators for whom that will be true. = I also > believe there are operators for whom 464XLAT with DNS64 is a viable and > useful option in some scenarios, particularly having to do with the costs= of > double translation. I'm not opposed to a document that attempts to lay o= ut > the trade-offs. I am very much opposed to a document that attempts to sa= y > there's only one way that works, because it isn't true. Indeed, for some > values of "works", _none_ of this qualifies, and the only real answer is = native > ipv6. >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DRSkkIe4IvPSsZ3MQjB0zrke22MCFWChjY3TS_hlIyu8&s=3D > vSMt4g-fkpgeb1fo2zsjL5D0DcFGs_nZzDf1agm1obo&e=3D From nobody Mon Jun 11 23:43: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 21C53130DFC for ; Mon, 11 Jun 2018 23:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoxI2MDs9wjM for ; Mon, 11 Jun 2018 23:43:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF675130DF9 for ; Mon, 11 Jun 2018 23:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528785828; x=1529390628; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=9c2ob94R 2BvlqwSHgDurzLYPNC6DidTCmTMXgKXTi/s=; b=v+yjO7NggFTMUQUv4WU/DUXp rDEnDcTSvni+SbaZgmQOQRpa/zG5QO+A8rA2OsG91/qvr0YZquU6I0TGPc0Pu+hc lr85dSr2V2DkKn9CAilg/rjpkozTw+i+UDo7zHqaRPW0DAQt9Bk8vdJJf/nx+FeA h4kpOtO0PBC+q0zAiH8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 12 Jun 2018 08:43:48 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 12 Jun 2018 08:43:47 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786602.msg for ; Tue, 12 Jun 2018 08:43:46 +0200 X-MDRemoteIP: 2001:470:1f09:495:ec21:6cb0:8f13:b068 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 12 Jun 2018 08:43:46 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17018db383=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 12 Jun 2018 08:43:44 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , 'Andrew Sullivan' , "v6ops@ietf.org" Message-ID: <06381673-28C9-4B8A-A2E8-46CFB2FBDFEB@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> <20180529193736.GA8084@mx4.yitter.info> <2D09D61DDFA73D4C884805CC7865E6114DDE6249@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDE6249@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 06:43:53 -0000 Thanks Barbara. Already working in a new version to accommodate to that, so I think it will= make sense for anyone willing to contribute, to wait until I've submitted = that version, unless is adding something substantially different to what An= drew provided.=20 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: martes, 12 de junio de 2018, 2:39 Para: 'Andrew Sullivan' , "v6ops@ietf.org" Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion I've been rather quiet on this, trying to figure out how to politely sa= y (with explanation) that I don't think this doc is in a state that would m= ake it acceptable as a WG draft. But in re-reading Andrew's response from a= few weeks ago, I think he's managed to put into words what some of my rese= rvations are. I'm top-posting on Andrew's email, with my summary of some of= the points he made, and my conclusions. A BCP that provides accurate and usable criteria for evaluating "which = NAT64 architecture is right for me" might be a good thing to produce. But t= his draft isn't it. This draft lacks WG consensus that it has the correct a= ssessment of the various architectural options. It is also not written in a= way that makes it easy to compare the pros and cons of the various options= against the needs of a network operator. The draft has potential, but isn'= t there (yet?). I don't have enough interest in this to spend the time needed to overco= me these objections. So raising these objections should not be seen as an o= bligation to actively provide the corrections needed to overcome these obje= ctions. Barbara =20 > -----Original Message----- > From: v6ops On Behalf Of Andrew Sullivan > Sent: Tuesday, May 29, 2018 3:38 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion >=20 > Hi, >=20 > On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote: >=20 > > I understand your point that NAT64 was meant to be "imperfect", but= this > is something that is not valid for operators. Operators need to suppo= rt > existing customers with existing devices and apps, that only have IPv= 4 > support, and this is only possible with NAT64 + CLAT. > > >=20 > Obviously, operators have customers and need to support whatever they > need to support. It appears that there are people who are using 464X= LAT > with DNS64 where that works for them. I certainly have no trouble wi= th > something that wants to outline (for instance) how one would make a > determination about whether anyone downstream is doing their own > validation. What I think is wrong here is a generic claim that one o= r another > approach is the only right answer, because the CLAT in many cases req= uires > more translation (which means more overhead and more work that the > operator has to do). >=20 > > Also, most of the actual usages of 464XLAT are still using DNS64 (e= xcept a > few like Orange in Poland if I recall correctly), so the point is to = explain that > you can also solve the DNSSEC issue, when using CLAT (not using DNS64= ), etc. > > >=20 > Well, you can indeed. I think there is nothing wrong with making thi= s point, > but the document as it is appears to be suggesting that the trade-off= is not > clear in DNS64. I think RFC 6147 is crystal clear about it, so I don= 't get why this > document (which has a much less comprehensive treatment of what fails > and why) is an improvement. >=20 > > So, the goal of the document is to find what is the "best" possible > > way to deploy NAT64, which in my opinion, in the real world is by > > using it combined with CLAT. >=20 > I don't observe that the document is called "Jordi's opinion on best > NAT64 deployment scenarios". If the WG is supposed to work on this, = then I > think it would be better to outline the various trade-offs and allow = people to > make their own choices, fully informed. >=20 > > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but = I > > wanted to do the exercise of looking into all possible cases, just = to > > make sure that somebody using the document see what is possible and > > what is not, instead of making the exercise by themselves. >=20 > I see. Such a section could be massively improved, then, by calling = out the > scenarios that are known not to work, that are broken on purpose, and= so > on. At the moment, it reads as though these alternatives are all liv= e > possibilities, but some of them simply aren't, were never intended to= be, and > are not a real problem anyone should have. >=20 > > What I disagree with you is in your comment that anyone who is will= ing to > deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is act= ually not > needed in that case. > > >=20 > I think what I said is that they're going to _be able_ to, not that t= hey would. I > do not claim that DNS64 ought to be deployed by anyone. > It's just a mechanism that is available if it happens to fit a need, = and each > network operator needs to evaluate that. I claim that the I-D as wri= tten > doesn't actually help people do such an evaluation, and that in fact = it leaves > out some of the necessary analysis. >=20 > > Maybe if you see the point that an operator will not be able to pro= vide > services without the CLAT, you have a better understanding on the > document now. > > >=20 > It's simply false that an operator will not be able to provide servic= e without > the CLAT, but it is true that _some_ operators will find such a servi= ce > inadequate. I believe that's why 464XLAT was invented, in fact. >=20 > > Would you agree that if an operator deploying IPv6-only access want= to > make sure that the customers using some IPv4-only devices work fine, = the > only way is using NAT64+CLAT, and that using NAT64+DNS64 will not wor= k? > > >=20 > No. But I believe that there are operators for whom that will be tru= e. I also > believe there are operators for whom 464XLAT with DNS64 is a viable a= nd > useful option in some scenarios, particularly having to do with the c= osts of > double translation. I'm not opposed to a document that attempts to l= ay out > the trade-offs. I am very much opposed to a document that attempts t= o say > there's only one way that works, because it isn't true. Indeed, for = some > values of "works", _none_ of this qualifies, and the only real answer= is native > ipv6. >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DRSkkIe4IvPSsZ3MQjB0zrke22MCFWChjY3TS_hlIyu8&s=3D > vSMt4g-fkpgeb1fo2zsjL5D0DcFGs_nZzDf1agm1obo&e=3D =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 11 23:52: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 7260E130F27; Mon, 11 Jun 2018 23:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naD8Krz-Xug5; Mon, 11 Jun 2018 23:51:58 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7250D130F59; Mon, 11 Jun 2018 23:51:58 -0700 (PDT) Received: from [192.168.10.187] (145.51-175-104.customer.lyse.net [51.175.104.145]) (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 674122D51BB; Tue, 12 Jun 2018 06:51:57 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-AC0801D0-5EDE-4A3A-95D7-C8ADA7BC2613 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Tue, 12 Jun 2018 08:51:54 +0200 Cc: "v6ops@ietf.org" , "fredbaker.ietf@gmail.com" , "intarea-chairs@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <4B2F5CB1-651E-42B0-A3E0-B75C8E82BD81@employees.org> References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> To: Simon Allard Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 06:52:03 -0000 --Apple-Mail-AC0801D0-5EDE-4A3A-95D7-C8ADA7BC2613 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Simon, I can=E2=80=99t recall right now if we wrote the general idea down, but ther= e is something similar alluded to in e.g 6RD.=20 Make the assertion that the CPE is responsible for the forwarding state in t= he BNG. State is maintained with DHCP. Lost state in the BNG is detected by t= he CPE using something akin to BFD echo mode.=20 I=E2=80=99d be happy if someone had time to write it up.=20 Cheers=20 Ole > On 11 Jun 2018, at 23:45, Simon Allard wrote: >=20 > Hi Fred >=20 > IPoE Health is something we have struggled with. We are a NZ based ISP wit= h a large IPoE customer base. >=20 > We are currently running our BNG's with 5 minute lease timers to try and g= et around the issue where the BNG declares the subscriber as dead and kills t= he session, however the client remains online until the lease expires. >=20 > We have had discussions with our CPE vendors around arp detection/resettin= g DHCP however those conversations have not gone well, with the CPE vendor s= aying that ARP and DHCP are 2 different things and can't be mixed. We also l= ooked at doing something similar with DNS (3 DNS request fail and it turns D= HCP into discovery mode), and BFD but nothing really got passed the whiteboa= rd discussions phase. >=20 > If there was an accepted RFC we could point the vendors at, it would make t= hose discussions much easier. >=20 > Cheers, > Simon > AS9790 >=20 >=20 > Simon Allard=E2=80=8B | Development & Operations Manager > D: +64 9 550 2790 E: Simon.Allard@vocusgroup.co.nz > M: +64 20 1000 790 W: vocusgroup.co.nz > A: Level 2, 1-7 The Strand, Takapuna 0622 > >=20 > ---------- Forwarded message --------- > From: Fred Baker > Date: Sat, 9 Jun 2018 at 22:58 > Subject: [v6ops] draft-patterson-intarea-ipoe-health > To: > Cc: >=20 >=20 > Looking for comments on draft-patterson-intarea-ipoe-health-00. The author= s would like to discuss it in v6ops at IETF 102 (Montreal). Do folks find it= interesting/useful? >=20 > The primary working group for this will be intarea, for reasons related to= the charter. However, it would be useful to know that the problem is a gene= ral one, and get comments on the proposed solution. >=20 > Sent from my iPad > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-AC0801D0-5EDE-4A3A-95D7-C8ADA7BC2613 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Simon,

=
I can=E2=80=99t recall right now if we wrote the general idea down, but= there is something similar alluded to in e.g 6RD. 

Make the assertion that the CPE is responsible for the forwarding stat= e in the BNG. State is maintained with DHCP. Lost state in the BNG is detect= ed by the CPE using something akin to BFD echo mode. 

I=E2=80=99d be happy if someone had time to write it up. 
=

Cheers 
Ole

On 11 Jun 2018,= at 23:45, Simon Allard <Simon.Allard=3D40vocusgroup.co.nz@dmarc.ietf.org>= wrote:

Hi Fred

IPoE He= alth is something we have struggled with. We are a NZ based ISP with a large= IPoE customer base.

We are currently running our BNG's with 5 minute= lease timers to try and get around the issue where the BNG declares the sub= scriber as dead and kills the session, however the client remains online unt= il the lease expires.

We have had discussions with our CPE vendors ar= ound arp detection/resetting DHCP however those conversations have not gone w= ell, with the CPE vendor saying that ARP and DHCP are 2 different things and= can't be mixed. We also looked at doing something similar with DNS (3 DNS r= equest fail and it turns DHCP into discovery mode), and BFD but nothing real= ly got passed the whiteboard discussions phase.

If there was an accep= ted RFC we could point the vendors at, it would make those discussions much e= asier.

Cheers,
Simon
AS9790


Simon Allard=E2=80= =8B | Development & Operations Manager
= =
D: = +64 9 550 2790 E: Simon.Allard@vocusgroup.co.nz
M: +64 20 1000&n= bsp;790  W: vocusgroup.co.nz
A: Level 2, 1-7 The Strand, Takapu= na 0622
<= image664000.png>
<= br>---------- Forwarded message ---------
From: Fred Baker <fredbaker.ietf@gmail.com>
= Date: Sat, 9 Jun 2018 at 22:58
Subject: [v6ops] draft-patterson-intarea-i= poe-health
To: <v6ops@ietf.org&g= t;
Cc: <intarea-chairs@ietf= .org>


Looking for comments on draft-patterson-intarea-ipoe= -health-00. The authors would like to discuss it in v6ops at IETF 102 (Montr= eal). Do folks find it interesting/useful?

The primary working group f= or this will be intarea, for reasons related to the charter. However, it wou= ld be useful to know that the problem is a general one, and get comments on t= he proposed solution.

Sent from my iPad
__________________________= _____________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
________________________________= _______________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo= /v6ops
= --Apple-Mail-AC0801D0-5EDE-4A3A-95D7-C8ADA7BC2613-- From nobody Tue Jun 12 02:01: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 A2666130E32 for ; Tue, 12 Jun 2018 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 7SpksmT6Gek4 for ; Tue, 12 Jun 2018 02:01:32 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97019130E18 for ; Tue, 12 Jun 2018 02:01:32 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v83-v6so14456859itc.3 for ; Tue, 12 Jun 2018 02:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7c5xvjhKOJrKqqui7Yqqlp+/B4r8KYihEh52pd7aRSE=; b=P70Y3zmMSTJPoOJypWcPJyhwl1EMdUoPChHtzyuUq1CBL2SDfQJOhjuIv77dlhy4hS uMKDPfCIyVN+Is1whQoo2xoeQGcEeHKkhzL9loDdrB+x3tpSE7LnA4Eu1r39N2s3tjRZ Zhfv1P8vmAWO6RE7DMcMWZdAbuXFcARq4HqbmN6c9cOAT/DxaC3LejRcIV2yrokd9vbM /tBcht28ABijajtOq9Woz5hOkSYBmUuMTsWo+o0JvoXHYMsN6yY7S+p8ipTCViyuLwUS OLmhbKKipm2hkdi7iXhPvMxXSOaR4nEK1YTRKRGtd0pYmYHX919ybx8fON+gp14qG38A av9w== 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=7c5xvjhKOJrKqqui7Yqqlp+/B4r8KYihEh52pd7aRSE=; b=QDdAYQoMRFwdhrMpzzvedRlIUiS/AN6EoWvW0DQYmHPejMS4viAPDd6RhgDtfp3STr hcvpBSran/MctmxtekB7LT49s/S+z+RnM4zBlB93NN7WAPbqy9aRYwBnTY88UkUOoToP gflKYoQeYjFgPz8EIlCLZuRFSmqQsehS78iXJcalcynq+qxNekUh+R5Biq9cLxsWSMPD EjrC0xMIgUn1mv9m+y0smxAqDiFyAjSKBnvOGNOP5B7rw/7r46bkMDskjFwDIR/r24W0 VVvQK5gwe8dXN+XeigQI1OfBdSJ7bM9e4LQStdW3oOlIPOVfm1qTu7l3Yt07Oce3HZml Nocg== X-Gm-Message-State: APt69E2RKpPe4mB2phsfi7ZFs09j6Z1Lwfhn0ruZEYAcZE1FRyZbECiV Fj1k1epKReF1Ty6pdVfBHLNg+a1U X-Google-Smtp-Source: ADUXVKJ/Hyocz5jge53z7sH/taM27a4b+1xPXcJj/fp+Jahce72r64o2O6BdkE6jhJ2psSdmeG9CiA== X-Received: by 2002:a24:2fc6:: with SMTP id j189-v6mr2408831itj.33.1528794091635; Tue, 12 Jun 2018 02:01:31 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id x8-v6sm234910ith.17.2018.06.12.02.01.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 02:01:30 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id p185-v6so14451099itp.4 for ; Tue, 12 Jun 2018 02:01:30 -0700 (PDT) X-Received: by 2002:a24:b21a:: with SMTP id u26-v6mr2249981ite.81.1528794090344; Tue, 12 Jun 2018 02:01:30 -0700 (PDT) MIME-Version: 1.0 References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> <4B2F5CB1-651E-42B0-A3E0-B75C8E82BD81@employees.org> In-Reply-To: <4B2F5CB1-651E-42B0-A3E0-B75C8E82BD81@employees.org> From: Richard Patterson Date: Tue, 12 Jun 2018 10:01:19 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000b0a7b9056e6e1c96" Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 09:01:37 -0000 --000000000000b0a7b9056e6e1c96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 12 Jun 2018 at 07:52, Ole Troan wrote: > Simon, > > I can=E2=80=99t recall right now if we wrote the general idea down, but t= here is > something similar alluded to in e.g 6RD. > > Make the assertion that the CPE is responsible for the forwarding state i= n > the BNG. State is maintained with DHCP. Lost state in the BNG is detected > by the CPE using something akin to BFD echo mode. > > I=E2=80=99d be happy if someone had time to write it up. > Broadband Forum's TR-146 suggests the use of BFD Echo as a detection mechanism, but it then only talks about triggering a renew, which often times won't help. I'm about to upload -01 of our draft which references TR-146, and now has a section for BFD Echo. This new section will prefer the use of BFD Echo as the health check mechanism over ARP/ND when it is available. If you could take a look at it and let us know if it's in-line with your thinking please= ? -Richard --000000000000b0a7b9056e6e1c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 12 Jun= 2018 at 07:52, Ole Troan <otroa= n@employees.org> wrote:
Simon,

I can=E2=80= =99t recall right now if we wrote the general idea down, but there is somet= hing similar alluded to in e.g 6RD.=C2=A0

Make the= assertion that the CPE is responsible for the forwarding state in the BNG.= State is maintained with DHCP. Lost state in the BNG is detected by the CP= E using something akin to BFD echo mode.=C2=A0

I= =E2=80=99d be happy if someone had time to write it up.=C2=A0


Broadband Forum's TR-146 = suggests the use of BFD Echo as a detection mechanism, but it then only tal= ks about triggering a renew, which often times won't help.
I'm about to upload -01 of our draft which references TR-1= 46, and now has a section for BFD Echo.=C2=A0 =C2=A0This new section will p= refer the use of BFD Echo as the health check mechanism over ARP/ND when it= is available.=C2=A0 =C2=A0If you could take a look at it and let us know i= f it's in-line with your thinking please?

-Ric= hard

--000000000000b0a7b9056e6e1c96-- From nobody Tue Jun 12 02:53: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 5E311130E1D for ; Tue, 12 Jun 2018 02:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch7nPZx7JbF4 for ; Tue, 12 Jun 2018 02:53:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E08B130E17 for ; Tue, 12 Jun 2018 02:53:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fSfzF-0000IRC; Tue, 12 Jun 2018 11:53:13 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> In-reply-to: Your message of "Mon, 11 Jun 2018 19:15:21 +0200 ." Date: Tue, 12 Jun 2018 11:53:13 +0200 Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 09:53:24 -0000 > I see your point, but > what an operator need is a "100% sure" way to make sure that they > can tell the CPE to not use a specific transition mechanism (which > for the other mechanisms we have with RFC8026). > > So, assuming that DNS64 is only there if combined with NAT64 is > not "safe 100%" because if using CLAT, you can avoid having a DNS64 > (this is the one that breaks DNSSEC, in case I wrote it incorrectly > before). I'm saying that if an operator uses DNS64 to signal the presence of NAT64, then that is a reliable signal that doesn't need an additional DHCP option. So if is safe for a CPE to just do RFC7050, because if DNS64 is detected, you can be sure that the operator wants the CPE to use NAT64. > But if the user changed the DNS in the CPE (which is quite common), > there will not be DNS64 and still may be the ISP want to have the > CLAT running, because is using that for the IPv4 service for that > particular customer. Yeah, what if the user changes settings? Maybe the CPE has a way to force NAT64 on. What do you do then? All bets are off when users start changing settings. In the context of RFC7050, the CPE can opt to use the original resolvers provided by upstream to figure out the translation prefix. Note that if the CPE uses resolvers configured by the user for RFC7050, then is it quite possible that the translation prefix is not discovered (for example if the user configures a well known public resolver). Or worse, the user may configure a DNS64 resolver that uses a different prefix. > If you agree that the CPE may request a PCP option, etc., then > request the S46, I think you are in agreement that we need the S46 > priority option codes for all the mechanism that we are asking to > be supported by the CPE, right? To the extent that RFC8026 is incomplete, that should be fixed. However as Section 2.2 describes, what S46 offers can be done already be done by the DHCPv6 server. So S46 just provides a relative priority of different mechanisms, not an on/off switch for NAT64. From nobody Tue Jun 12 02:56: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 7AB44131143 for ; Tue, 12 Jun 2018 02:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Mb-t_uGAmsno for ; Tue, 12 Jun 2018 02:56:51 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0245D130F93 for ; Tue, 12 Jun 2018 02:56:50 -0700 (PDT) Received: from h.hanazo.no (unknown [173.38.220.43]) (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 8506A2D5025; Tue, 12 Jun 2018 09:56:49 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7ECD22031D0C6B; Tue, 12 Jun 2018 11:56:45 +0200 (CEST) From: Ole Troan Message-Id: <95A06F3D-5997-4E5C-99B8-1B03F0ED0B5D@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_46771A35-DA62-4E27-9774-59861105F3E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 12 Jun 2018 11:56:44 +0200 In-Reply-To: Cc: "v6ops@ietf.org list" To: Richard Patterson References: <8D359534-A3DA-4F25-98A7-4AC931A3D6F5@gmail.com> <4B2F5CB1-651E-42B0-A3E0-B75C8E82BD81@employees.org> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 09:56:54 -0000 --Apple-Mail=_46771A35-DA62-4E27-9774-59861105F3E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Richard, > I can=E2=80=99t recall right now if we wrote the general idea down, = but there is something similar alluded to in e.g 6RD. >=20 > Make the assertion that the CPE is responsible for the forwarding = state in the BNG. State is maintained with DHCP. Lost state in the BNG = is detected by the CPE using something akin to BFD echo mode. >=20 > I=E2=80=99d be happy if someone had time to write it up. >=20 >=20 > Broadband Forum's TR-146 suggests the use of BFD Echo as a detection = mechanism, but it then only talks about triggering a renew, which often = times won't help. >=20 > I'm about to upload -01 of our draft which references TR-146, and now = has a section for BFD Echo. This new section will prefer the use of = BFD Echo as the health check mechanism over ARP/ND when it is available. = If you could take a look at it and let us know if it's in-line with = your thinking please? Ah, yes that's where it ended up. ;-) Of course it doesn't have to be an actual BFD packet for that matter. = But BFD echo has the whole framework described, so that's probably = useful to reuse. The only thing required is that the CPE can send a packet to itself via = the BNG. Cheers, Ole --Apple-Mail=_46771A35-DA62-4E27-9774-59861105F3E7 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+/bDNdvtpYqJhC33YFAlsfmNwACgkQvtpYqJhC 33aF+BAAt3ntVmmBccvqsWyqpmBzykSw5MBgCjHpq3JlouNMUqHFImLt27w2WHIO yyNzb1Z/8Xe9lwmVPaONmaMqAgG/J2ICEY/7x1eDOvHGg+FdKJygssrNtB19vUC7 euBgQmGFfop1HWYxkYIFtlg4jp2pjSumnyAMB4DC+mKZQZXv8zhm/UKWtHg4x0bV gSeHb5NNKD16TPmsova5l2Wobt4ZWhg+iBAI9Kj7bnpHgf9wlxwNxhBjitbz6DZg ePISNFEiHciCSyVpJNu2Z583kH7gZY1KqwIJhhkzzlf2KR09KO92BoxZNuuPlO7l gM5z8MHyg+nt3JL3R1g3QVfsmev7MncbClPwL8mYnfvACD9HjfmxdTxQTDaA8+4h eq9lH3U35Te1qLU/fu09C5/6LP8fvOXLgzg+txxlIB5EqzylLj9CMJ/bDdkyvUo1 2VnhYmq3Se6ta+iWAgShtfRMFTx/1tkALVghE2wfhHKGH6IaBbp01N9yVkNHOXPj 7EwXDTf3xIkvHmchqaEzSyYNhu3hCu6C/muyuKWJ2dVuslN69xDyuRHW1K5RY0E7 Xks4bvofQHbxvi4yPzM/hriEyZsCuGUjCc+pL22vIJSCcqvpKruKRQNH+i3gQNy0 OLP84US4jyyvX7/tQ61OWgfj3XfMmdx1TKo9xBQB7s2hxmz2KlY= =djBM -----END PGP SIGNATURE----- --Apple-Mail=_46771A35-DA62-4E27-9774-59861105F3E7-- From nobody Tue Jun 12 03:13: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 39FCE130F3F for ; Tue, 12 Jun 2018 03:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 7GZZrmfoZA5I for ; Tue, 12 Jun 2018 03:13:00 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECCC130E1D for ; Tue, 12 Jun 2018 03:13:00 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id j15-v6so22214134wme.0 for ; Tue, 12 Jun 2018 03:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cda8YTuc2+yjxtke7Gd4zGcUuz+CUpcir3o3rxucd+M=; b=ROhKbSuU5wKa2bLmwWvKNkgP0Evr8MwlZMyqFzdHNDMLVT1jaN076bMo3Up6+kFtcx rJQLhhTwgzy5/r/A+e+zrkN7koVXUlNOgzpQ1aFAkbDsA3T8m6CPBlkKZVirF3IKDgF8 /n5lyV/HKrCbdj9D11vnFLkOh6O211ge0ruN8rtGVMCd8ZhflBeUh1eJ0bjXFbz0tBZU rFaCFCjpV89kC/sMdeLU7KZdGtzk3FJWyk3XPaZrEUYYgvG9sjo2x1obw62c2iyXGA5x 57JOqKx69/P3IM1iDCSTG3bE4lqCxe9fFkO5SqswMske0XmcsrqJRbgUE9YRMiyIRaDj CfUQ== 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=Cda8YTuc2+yjxtke7Gd4zGcUuz+CUpcir3o3rxucd+M=; b=CG2l4Uhn6VDQ3Ejq/LZ6UDDxII2i34OptQ31hhoqYzrLevOjItzRaJt+gkpaCXeEdR YKPamoxaV7fFWBwp8urzx3rcSVNtHZ4lKPNfPVaq8kBJSCCSCO1v9Jf/lD+TaeZGtQ/i W8fvNpaReaJ3aXX58REqK6ibrAFiQTyTjgEh4Fit3wXG+FpaJfF97+OXroU8OzQEFKCP T16R4haFasXjA6Mx4OiI54IMK4EXtqGc2WJ8uLv+KUiTLBoAGjRdW+qI3cBFpQsU8bNt n9NFQSON/WRzyXxRbllR98vzhe1e3eOSQfDfZrYwPjpgMy2GBg8C66blJ9/y6juTRVCl 07vg== X-Gm-Message-State: APt69E3X4Xj6UKvM3xv2xx7j42+G7n0bL3s2BGxAJtQ+NUZGDm5f2u47 H/DtZy2hwpq3XxEzJftmOREvIJYEGT1PXGUCNyRTmTxbzlo= X-Google-Smtp-Source: ADUXVKLUBnmSx3O4PNnC50CajvUjVQzS6Sn8Tw3ooumCjt8YjbReYEWy7KhxHyb4PFUhTSlDwuqYCoElVWYYLG6j4ng= X-Received: by 2002:a1c:f014:: with SMTP id a20-v6mr1567607wmb.97.1528798378321; Tue, 12 Jun 2018 03:12:58 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-Reply-To: From: Lorenzo Colitti Date: Tue, 12 Jun 2018 19:12:44 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000046c78c056e6f1c5b" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 10:13:04 -0000 --00000000000046c78c056e6f1c5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2018 at 9:55 PM JORDI PALET MARTINEZ wrote: > The point is the ISP to be able to turn on or off each mechanism (464XLAT= , > MAP, DS-Lite, etc.), and this is easily done if all them share the same > DHCP option. > > The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS > servers that don't do DNS64 translation. > > > > No, that is not a solution, at least not for the scope of what is needed > in this document. > > You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so that > will not work. > If you don't use DNS64 you can't use 464xlat at all, because you can't communicate the plat prefix to the clat. Also, users tend to change their DNS servers, so once more this doesn=E2=80= =99t > work. > Per the above: if the users change the DNS servers, 464xlat will stop working regardless of what the ISP says. > I will like to understand if we still have such opposition, why. > > Because it requires additional standards work, engineering work and > implementation complexity to achieve something that is already possible > today using RFC 7050. > > > > I believe you=E2=80=99re misunderstanding what is needed here. I=E2=80=99= m not talking > about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the NAT64 prefix or serv= er. This is > already done by RFC7050 or RFC7225 (PCP). > > It is not a NEW DHCPv6 protocol. Is a new option code in an existing > protocol (RFC8026). There is nothing new to develop. We just need to tell > IANA =E2=80=9Cin addition to the already defined option codes for DS-LITE= , MAP, > etc., define one for 464XLAT=E2=80=9D. > I still don't see a use case for this. If an operator uses 464xlat, they must use RFC 7050 to provision it because there is no other mechanism. Additionally, if the user changes the DNS server to a non-DNS64 server, 464xlat stops working, and if the user changes the DNS server to a DNS64 server that doesn't hand out the operator's NAT64 prefix, 464xlat stops working or only works suboptimally. There is nothing the operator can do about this except accept the breakage or prevent the user from changing the DNS server. Therefore, I think the following covers all cases: 1. If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE. 3. If the operator uses 464xlat, they should not allow the user to change the DNS server. --00000000000046c78c056e6f1c5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 11= , 2018 at 9:55 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wr= ote:

Th= e point is the ISP to be able to turn on or off each mechanism (464XLAT, MA= P, DS-Lite, etc.), and this is easily done if all them share the same DHCP = option.=C2=A0

The ISP can easily turn off 464xlat via DHCPv6 toda= y: just provide DNS servers that don't do DNS64 translation.<= /u>

=C2=A0

No, that is not a solution, at least no= t for the scope of what is needed in this document.

You can run 464XLAT without DN= S64, so to avoid breaking DNSSEC, so that will not work.


If you don't use DNS64 you c= an't use 464xlat at all, because you can't communicate the plat pre= fix to the clat.

Also, users tend to cha= nge their DNS servers, so once more this doesn=E2=80=99t work.=C2=A0=


Per the above: if th= e users change the DNS servers, 464xlat will stop working regardless of wha= t the ISP says.

I will like to understand if we still have such opp= osition, why.=C2=A0

Because it requires additional standard= s work, engineering work and implementation complexity to achieve something= that is already possible today using RFC 7050.

=C2=A0

I believe you=E2=80=99re misunderstanding what is needed here. I=E2= =80=99m not talking about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the NA= T64 prefix or server. This is already done by RFC7050 or RFC7225 (PCP). =

It is not= a NEW DHCPv6 protocol. Is a new option code in an existing protocol (RFC80= 26). There is nothing new to develop. We just need to tell IANA =E2=80=9Cin= addition to the already defined option codes for DS-LITE, MAP, etc., defin= e one for 464XLAT=E2=80=9D.

<= br>
I still don't see a use case for this. If an operator use= s 464xlat, they must use RFC 7050 to provision it because there is no other= mechanism. Additionally, if the user changes the DNS server to a non-DNS64= server, 464xlat stops working, and if the user changes the DNS server to a= DNS64 server that doesn't hand out the operator's NAT64 prefix, 46= 4xlat stops working or only works suboptimally. There is nothing the operat= or can do about this except accept the breakage or prevent the user from ch= anging the DNS server.

Therefore, I think the foll= owing covers all cases:
  1. If the operator wants to enable 4= 64xlat: they should hand out a DNS64 to the CPE.
  2. If the operator wa= nts to disable=C2=A0464xlat: they should NOT hand out a DNS64 to the CPE.
  3. If the operator uses 464xlat, they should not allow the user to chan= ge the DNS server.
--00000000000046c78c056e6f1c5b-- From nobody Tue Jun 12 03:14: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 5094F130F3C for ; Tue, 12 Jun 2018 03:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 qaaZOaWFhuBE for ; Tue, 12 Jun 2018 03:14:20 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0D5130F41 for ; Tue, 12 Jun 2018 03:14:07 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id v131-v6so22144655wma.1 for ; Tue, 12 Jun 2018 03:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g1Xqczwc2Mq42qDAZyQj0WEA/qzS9z2obHxnEuMZBsI=; b=Xulq9xXHKHZe3HluYsGKonvb+UVjLjNDbvzpuvJDTQdJj8EX/wHLtrtOqrA6zQCNfe Qbdbi1rrcL6LUHUrOHc1FsycyHgHTFVzl+yFpId7rkww77sZEUNalkQ9OV4s6UA+NqdJ 28sni2mn/mAjgv6V5YeMT3uetWJPE2xh/c/Y2PhusF4likwdnp1RVRjH7iHkODrQvk+u Yx8/izvB1E8gPWRsh0SvMdbRlc5BfRuHxu3owKHPEPRlA7Yin2s5vjDoGGd9CvzLFo/j xzisBSRZ/YoK1Zq7PheDZQNf1s/L6Ah+ycyUct1D2iME+CsgyetlH+i/XNluH47OZRoz RRTA== 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=g1Xqczwc2Mq42qDAZyQj0WEA/qzS9z2obHxnEuMZBsI=; b=SLdGkKMrzMfA5nsTCgqDRHHLNhJ5siU306wEGStcKMjbOBY6xLHVogcjvi3mWBJl67 E/OgZfffTeh146TZV4CFBk6bBreSW3YwIgyC/zsxY6uEfYq5eB56ENS5PUt667cbPNjr vN/ZQNWrPmtK42enwu2dC+FwKUjoqTahIpNrDGZf3YgUlEAA/mgPIC7lhI1JT2QAcjYu GHXC4YRSJpeUpHOH/XMv9T6Z5SH7D9HI/Jleprb58Woy7BLomtbjRLtYRr1KmDgdLwzW 0h7HMvlyAbqOGAtlfv3YzHc/tSWepILNy8xyXtB5UHXQ7TvmZ8O3A9dEDc0pNkpGIL1E qFSA== X-Gm-Message-State: APt69E1u+1qk8NkV7TmwQa2vA7LOmYndOrGMJlYNu1g/FjpfC+NnTlY0 bqetQIJkalL4PBYX2KQoZoJy+DWr2PweMZ9r5iXDvA== X-Google-Smtp-Source: ADUXVKITCO6kpDEjiwRhw2b8e9NmLfPFwyWj8FKymzNznGjNoLEW6AgezACl6WneesGbmUe0FqsGEe4Abry6OHlKFxg= X-Received: by 2002:a1c:d2cb:: with SMTP id j194-v6mr1577277wmg.129.1528798445776; Tue, 12 Jun 2018 03:14:05 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> In-Reply-To: From: Lorenzo Colitti Date: Tue, 12 Jun 2018 19:13:53 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: pch-v6ops-8@u-1.phicoh.com, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000004b96fd056e6f2087" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 10:14:26 -0000 --0000000000004b96fd056e6f2087 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 2:15 AM JORDI PALET MARTINEZ wrote: > But if the user changed the DNS in the CPE (which is quite common), there > will not be DNS64 and still may be the ISP want to have the CLAT running, > because is using that for the IPv4 service for that particular customer. > You can't use 464xlat without DNS64 as there is no way to configure the plat prefix. --0000000000004b96fd056e6f2087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12= , 2018 at 2:15 AM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wr= ote:
But if the user changed the DN= S in the CPE (which is quite common), there will not be DNS64 and still may= be the ISP want to have the CLAT running, because is using that for the IP= v4 service for that particular customer.

You can't use 464xlat without DNS64 as there is no way to configure t= he plat prefix.
--0000000000004b96fd056e6f2087-- From nobody Tue Jun 12 03:40: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 8AE08130F3F for ; Tue, 12 Jun 2018 03:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae-0p-KTj8j9 for ; Tue, 12 Jun 2018 03:40:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F3B130DCB for ; Tue, 12 Jun 2018 03:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528800025; x=1529404825; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=9fkdVILylMubaaiy/4y/ip kEocX4DPEML3PuUAWWqgU=; b=FLBPNbg98iDNj1WKWHrwnZ+ULjDf/xeUUBDduu z6ijaIcKSg75OEFUXWR1uxG9+ax/B0lExC9wD9YU3+rDAETKE+hdcu3gWisFJFFZ cReC7tH4//6kr96DYgyOQlPgPaPBtPNFLREZK1XlzndGTZt0aSiydqP5Kof5nJyq qHaic= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 12 Jun 2018 12:40:25 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 12 Jun 2018 12:40:24 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786756.msg for ; Tue, 12 Jun 2018 12:40:24 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c6a:90f6:6939:19da X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 12 Jun 2018 12:40:24 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17018db383=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 12 Jun 2018 12:40:22 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Message-ID: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611652022_904552995" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 10:40:33 -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_3611652022_904552995 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Lorenzo, =20 You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225). =20 1. If the operator wants to enable 464xlat: they should hand out a DN= S64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does. =20 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. =20 =20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6 So that means that if instead o= f enforcing DNS64 mechanism (RFC7050) to communicate the NAT64 prefix, you = use an alternative way such at RFC7225, it becomes safer to unwanted user c= hanges. Regards, Jordi =20 =20 =20 De: Lorenzo Colitti Fecha: martes, 12 de junio de 2018, 12:13 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Mon, Jun 11, 2018 at 9:55 PM JORDI PALET MARTINEZ wrote: The point is the ISP to be able to turn on or off each mechanism (464XLAT, = MAP, DS-Lite, etc.), and this is easily done if all them share the same DHC= P option.=20 The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS serv= ers that don't do DNS64 translation. =20 No, that is not a solution, at least not for the scope of what is needed in= this document. You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so that wil= l not work. =20 If you don't use DNS64 you can't use 464xlat at all, because you can't comm= unicate the plat prefix to the clat. =20 Also, users tend to change their DNS servers, so once more this doesn=E2=80= =99t work.=20 =20 Per the above: if the users change the DNS servers, 464xlat will stop worki= ng regardless of what the ISP says. I will like to understand if we still have such opposition, why.=20 Because it requires additional standards work, engineering work and impleme= ntation complexity to achieve something that is already possible today usin= g RFC 7050. =20 I believe you=E2=80=99re misunderstanding what is needed here. I=E2=80=99m = not talking about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the NAT64 pref= ix or server. This is already done by RFC7050 or RFC7225 (PCP).=20 It is not a NEW DHCPv6 protocol. Is a new option code in an existing protoc= ol (RFC8026). There is nothing new to develop. We just need to tell IANA = =E2=80=9Cin addition to the already defined option codes for DS-LITE, MAP, = etc., define one for 464XLAT=E2=80=9D. =20 I still don't see a use case for this. If an operator uses 464xlat, they mu= st use RFC 7050 to provision it because there is no other mechanism. Additi= onally, if the user changes the DNS server to a non-DNS64 server, 464xlat s= tops working, and if the user changes the DNS server to a DNS64 server that= doesn't hand out the operator's NAT64 prefix, 464xlat stops working or onl= y works suboptimally. There is nothing the operator can do about this excep= t accept the breakage or prevent the user from changing the DNS server. =20 Therefore, I think the following covers all cases: If the operator wants to enable 464xlat: they should hand out a DNS64 to th= e CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611652022_904552995 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Lorenzo,

 

You don=E2=80=99t need RFC7050 neither DNS64, y= ou can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provide= s additional advantages to the operator to control many related aspects (se= e section 3 of RFC7225).

 

1.      = ; If the operator wants t= o enable 464xlat: they should hand out a DNS64 to the CPE.

= 2.<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp; If the operator wan= ts to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn=E2=80=99t work, bec= ause the operator may be using RFC7225 instead of RFC7050. You need to try = both in that case, and you aren=E2=80=99t providing a =E2=80=9Cpriority=E2= =80=9D to a possible list of mechanisms, which is what RFC8026 does.

 

3.       If the operator uses 464xlat,= they should not allow the user to change the DNS server.=

 

 

Let=E2=80= =99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the customer t= o avoid changing the DNS =E2=80=A6 So that means that if instead of enforci= ng DNS64 mechanism (RFC7050) to communicate the NAT64 prefix, you use an al= ternative way such at RFC7225, it becomes safer to unwanted user changes.


Regards,

Jordi

 

 

 

De: Lorenzo Colitti <lorenzo=3D40google.com@dmarc.= ietf.org>
Fecha: martes, 12 de junio de 2018, 12:13
Para: <jordi.palet@consul= intel.es>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org= >
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in d= raft-ietf-v6ops-transition-ipv4aas

 

<= div>

On Mon, Jun 11, = 2018 at 9:55 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrot= e:

=

The point is th= e ISP to be able to turn on or off each mechanism (464XLAT, MAP, DS-Lite, e= tc.), and this is easily done if all them share the same DHCP option. =

The = ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS servers = that don't do DNS64 translation.

 

= No, that is not a solution, at least not for the scope of what is needed in= this document.

You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so= that will not work.

 

<= /div>

If you don't us= e DNS64 you can't use 464xlat at all, because you can't communicate the pla= t prefix to the clat.

 

Also, users tend to change their DNS servers, so once more thi= s doesn=E2=80=99t work. 

 

Per th= e above: if the users change the DNS servers, 464xlat will stop working reg= ardless of what the ISP says.

I will like to understand if we still have s= uch opposition, why. 

Because it requires additional standards work,= engineering work and implementation complexity to achieve something that i= s already possible today using RFC 7050.

 

I believe you=E2=80=99re misunderstanding what is needed here. I=E2=80= =99m not talking about a new DHCPv6 way to =E2=80=9Cfind=E2=80=9D the NAT64= prefix or server. This is already done by RFC7050 or RFC7225 (PCP).

It is not a NE= W DHCPv6 protocol. Is a new option code in an existing protocol (RFC8026). = There is nothing new to develop. We just need to tell IANA =E2=80=9Cin addi= tion to the already defined option codes for DS-LITE, MAP, etc., define one= for 464XLAT=E2=80=9D.

=

 

I still don't= see a use case for this. If an operator uses 464xlat, they must use RFC 70= 50 to provision it because there is no other mechanism. Additionally, if th= e user changes the DNS server to a non-DNS64 server, 464xlat stops working,= and if the user changes the DNS server to a DNS64 server that doesn't hand= out the operator's NAT64 prefix, 464xlat stops working or only works subop= timally. There is nothing the operator can do about this except accept the = breakage or prevent the user from changing the DNS server.

 

Therefore= , I think the following covers all cases:

  1. If the operator wants to ena= ble 464xlat: they should hand out a DNS64 to the CPE.
<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto;margin-left:71.4pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2'>2.       If the operator wants to disable 464xlat: they should NOT hand ou= t a DNS64 to the CPE.

3.   &= nbsp;   If the operator uses 464xlat, the= y should not allow the user to change the DNS server.

<= /div>

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611652022_904552995-- From nobody Tue Jun 12 03:48:20 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 67F72130E1F for ; Tue, 12 Jun 2018 03:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySYE4cochfoB for ; Tue, 12 Jun 2018 03:48:11 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CF612F1A5 for ; Tue, 12 Jun 2018 03:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528800489; x=1529405289; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=G8ynAHy8 JnVFLLAvnKP96PIsj6eyWXWxbI2Cs7P6ETI=; b=EE+ETyXX0yWUqSUQk+qHD96Y hhSe5r85Zkvb8W3oS/LvnrrkLid0Vvu55i0fYSI/7ApXSVyPxnwmk71ydudqyjDM Kqd4JiQJYbKUAqocFPBDrN7eQwvtexPNFM/s57RnYXay40CVtynKAtxYZPFm8Ok2 LmU5J8XUUZX2qAXQa5s= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 12 Jun 2018 12:48:09 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 12 Jun 2018 12:48:09 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005786759.msg for ; Tue, 12 Jun 2018 12:48:09 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c6a:90f6:6939:19da X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 12 Jun 2018 12:48:09 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17018db383=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 12 Jun 2018 12:48:07 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 10:48:16 -0000 I think my earlier email to Lorenzo provides answers to most of this ... but > I see your point, but > what an operator need is a "100% sure" way to make sure that they > can tell the CPE to not use a specific transition mechanism (which > for the other mechanisms we have with RFC8026). > > So, assuming that DNS64 is only there if combined with NAT64 is > not "safe 100%" because if using CLAT, you can avoid having a DNS64 > (this is the one that breaks DNSSEC, in case I wrote it incorrectly > before). I'm saying that if an operator uses DNS64 to signal the presence of NAT64, then that is a reliable signal that doesn't need an additional DHCP option. So if is safe for a CPE to just do RFC7050, because if DNS64 is detected, you can be sure that the operator wants the CPE to use NAT64. As said, you can use the CLAT w/o DNS64, so it is not a safe way to detect the CPE should use or not the NAT64. > But if the user changed the DNS in the CPE (which is quite common), > there will not be DNS64 and still may be the ISP want to have the > CLAT running, because is using that for the IPv4 service for that > particular customer. Yeah, what if the user changes settings? Maybe the CPE has a way to force NAT64 on. What do you do then? All bets are off when users start changing settings. An operator wants to make it as proof as possible to user changes. A user has no interest in changing the status of NAT64 (probably they don't know what it means), but they have interested in changing the DNS, because many apps or web sites tell them to change it. In the context of RFC7050, the CPE can opt to use the original resolvers provided by upstream to figure out the translation prefix. Note that if the CPE uses resolvers configured by the user for RFC7050, then is it quite possible that the translation prefix is not discovered (for example if the user configures a well known public resolver). Or worse, the user may configure a DNS64 resolver that uses a different prefix. Right, that's one case, using an alternative DNS64, which will bring alternative NAT64, unless/or the operator is using PCP for the NAT64 provisioning. > If you agree that the CPE may request a PCP option, etc., then > request the S46, I think you are in agreement that we need the S46 > priority option codes for all the mechanism that we are asking to > be supported by the CPE, right? To the extent that RFC8026 is incomplete, that should be fixed. However as Section 2.2 describes, what S46 offers can be done already be done by the DHCPv6 server. So S46 just provides a relative priority of different mechanisms, not an on/off switch for NAT64. What it makes this work is the combination of RFC8026 and the CPE behavior. The idea is to have a S46 option to provide a priority in a list of "possible" transition mechanism to a given CPE. If the operator doesn't want that a specific CPE uses NAT64, then the S46 will not contain that option, so the CE will not use it, because will not have a match (even if the CPE is able to use 464XLAT). Not sure if this explanation clarify it ? I'm working on the precise text for that in the ID ... ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Tue Jun 12 04:11:20 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 26ECF130DDA for ; Tue, 12 Jun 2018 04:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 4Uw4A_a980cF for ; Tue, 12 Jun 2018 04:11:13 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61C3130E13 for ; Tue, 12 Jun 2018 04:11:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id u4-v6so27566328iof.2 for ; Tue, 12 Jun 2018 04:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=pLjjOtvK6xkxv6tkN4pxzHaxG63laXNHdRed7vsbS+8=; b=G3XSRdqhyoLuPMw7Y9jKo3fs/iWyGrVvrrCqczFtfVnjE2r3gCDTRXPzSYhutXN9En D9njSma1zDzwcSULmRuByvPyz9OI0rfL9N/3LyCZNi2/R+pX/i11derG4rd7JRtD0m0A HPEsozx58mEcewYislVlxy164V21wIJedxULRXxtCmGTdRxwurt2/Ssof1cc09UKq6PT sBBkLZF7l5bSTDDX49nTUfsNeQftlYVNW9ewwXTfdeHud+Ar+NCCIx9qyZxJTuD/yabs pMlhXofFyP2esmfX60uI/NPf0w7IpN9sCtZ/xnxBVMltUZwQoo0rM3R0eoL0WF0dgUyb EXig== 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:content-transfer-encoding; bh=pLjjOtvK6xkxv6tkN4pxzHaxG63laXNHdRed7vsbS+8=; b=swDAWn2fQKDHgXZIZtUyeGhnT2WtKYZTr/0LXQAdfjbZJwAhhNzxookCnewJqCpzs2 DMPy+R/kYJUuk1Mlkhq3eQ362Fs8m+S60tCsYWCGBLufItHvPY1qQzGZAjL73dpoPk/r f+EFjboAl6k2iXZe5RpYcBKCvYv+j5JCu5GOH9uSy6BM8OEVZ4NR09ajxzlHviMW5NoQ fLOSwIaNJuI1Drd3z5tcXGAKC341pch6H96aKuSLoqtlck/ybqq3joLBj3iLhCR780ex SzvRMdLyZ8FVP7diq9KT4qjNhK0Xyca+qk06cH1P+0xiUstPCuo+tjrrtgM0TMErP0xf 5f3g== X-Gm-Message-State: APt69E1HB7TZynmp8+RsD/TMD+mZPO9ezfsgjJy7AKtbXWJQgrG/7o+P 6Cqq9BW7DICv0aIZUVTp46ZgJ6WR X-Google-Smtp-Source: ADUXVKJkpVTu+kSCnHhChyeTjKhxJKd6FClK3X6T6QtMZNvGRFbCKu9s0DP9inL+loQyjszcbc7vgg== X-Received: by 2002:a6b:4f0d:: with SMTP id d13-v6mr2784906iob.228.1528801872979; Tue, 12 Jun 2018 04:11:12 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id p23-v6sm47957itf.39.2018.06.12.04.11.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 04:11:12 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id t6-v6so27518559iob.10 for ; Tue, 12 Jun 2018 04:11:12 -0700 (PDT) X-Received: by 2002:a6b:8e0d:: with SMTP id q13-v6mr2832471iod.169.1528801872264; Tue, 12 Jun 2018 04:11:12 -0700 (PDT) MIME-Version: 1.0 References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> In-Reply-To: From: Richard Patterson Date: Tue, 12 Jun 2018 12:11:01 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 11:11:18 -0000 A new version of draft-patterson-intarea-ipoe-health has been posted. The major change since -00, is the inclusion and preference of BFD Echo as the health check mechanism when available. The draft now has an informational reference to Broadband Forum's TR-146 document which also discusses this problem. The authors believe that this draft builds on the method suggested in TR-146 in the following ways: - Prefers BFD Echo, but allows for ARP/ND methods when not available. - Defaults to DHCP renew as an action, but specifies optional alternative actions to expedite recovery. - Provides a DHCP Option to allow network administrators to signal parameters dynamically to CEs. =EF=BB=BFOn 12/06/2018, 10:11, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-patterson-intarea-ipoe-health-01.txt has been successfully submitted by Richard Patterson and posted to the IETF repository. Name:draft-patterson-intarea-ipoe-health Revision:01 Title:IPoE Client Health Checking Document date:2018-06-12 Group:Individual Submission Pages:12 URL: https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-01= .txt Status: https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ Htmlized: https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-patterson-intarea-ipoe-health-01 Abstract: PPP over Ethernet clients have the functionality to detect path unavailability by using PPP Keepalives. IP over Ethernet does not have this functionality, and it's not specified when an IP over Ethernet client should consider its WAN connectivity down, unless there is a physical layer link down event. This document describes a way for IP over Ethernet clients to achiev= e connectivity validation, similar to that of PPP over Ethernet, by using BFD Echo, or ARP and Neighbor Discovery functions. Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jun 12 08:07: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 83BAF130E5B for ; Tue, 12 Jun 2018 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 G2T1YvErpYta for ; Tue, 12 Jun 2018 08:07:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0604130E54 for ; Tue, 12 Jun 2018 08:07:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GcAAD14B9b/wUHmMZcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJwU2JtEigKg22IBIxogX+UW4E9OwsjCQKEPgIXghwhNBgBAgE?= =?us-ascii?q?BAQEBAQICAmkcDIJoMQQHAwwhCQIwAQEBAQEBIwIPNRIBARgBAQEBAxIREToJD?= =?us-ascii?q?gQCAQgNBAQBAQECAgYdAwICAjAUAQgIAgQBEggagwKBfwEOoHCJbIIcGgKIKoF?= =?us-ascii?q?ogQuHPYFVPoQbgxECAgEXgTAYFYJpMYIkAow2jFAJAoVxikVBgz2CV4UeigmHL?= =?us-ascii?q?4FBOYFScBUaIYJDCYITLYM0hRSFPm+BFYw7K4EBAYEZAQE?= X-IPAS-Result: =?us-ascii?q?A2GcAAD14B9b/wUHmMZcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?wU2JtEigKg22IBIxogX+UW4E9OwsjCQKEPgIXghwhNBgBAgEBAQEBAQICAmkcD?= =?us-ascii?q?IJoMQQHAwwhCQIwAQEBAQEBIwIPNRIBARgBAQEBAxIREToJDgQCAQgNBAQBAQE?= =?us-ascii?q?CAgYdAwICAjAUAQgIAgQBEggagwKBfwEOoHCJbIIcGgKIKoFogQuHPYFVPoQbg?= =?us-ascii?q?xECAgEXgTAYFYJpMYIkAow2jFAJAoVxikVBgz2CV4UeigmHL4FBOYFScBUaIYJ?= =?us-ascii?q?DCYITLYM0hRSFPm+BFYw7K4EBAYEZAQE?= X-IronPort-AV: E=Sophos;i="5.51,215,1526356800"; d="scan'208";a="244241965" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jun 2018 11:06:37 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 11:06:36 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 12 Jun 2018 11:06:35 -0400 From: "Mudric, Dusan (Dusan)" To: Richard Patterson , "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt Thread-Index: AQHUAj48Q+0soWtnZE2MJIS2QBWzJqRctR+Q Date: Tue, 12 Jun 2018 15:06:34 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 15:07:33 -0000 SGkgUmljaGFyZCwNCg0KIjQuMy4gIEJlaGF2aW91ciAyOiBFeHBpcmUgTGVhc2UiDQoNClR5cG86 IEJlaGF2aW9yDQoNCi0gSXMgdGhpcyBvcHRpb24gYW4gYXR0ZW1wdCBmb3IgdGhlIGxlYXNlIFJF TkVXLWFsIGJ1dCBub3QgdXNpbmcgUkVORVc/DQotIElmIG5vdCwgd2hhdCBpcyB0aGUgYmVuZWZp dCBvZiBub3Qgc2VuZGluZyBSRUxFQVNFPyANCi0gSWYgeWVzLCBpcyBESENQdjYgY2xpZW50IGdv aW5nIHRvIHNlbmQgdGhlIHNhbWUgYWRkcmVzcyBpbiBTT0xJQ0lUPyBJcyBESENQdjYgY2xpZW50 IGdvaW5nIHRvIHVuaWNhc3QgU09MSUNJVCB0byB0aGUgc2FtZSBESENQdjYgc2VydmVyLCBpZiBP UFRJT05fVU5JQ0FTVCB3YXMgc2V0IGZvciB0aGUgbGVhc2U/DQoNClRoYW5rcywNCkR1c2FuLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZv cHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQNCj4gUGF0dGVyc29uDQo+ IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTggNzoxMSBBTQ0KPiBUbzogdjZvcHNAaWV0Zi5v cmcgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt2Nm9wc10gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1wYXR0ZXJzb24taW50YXJlYS1pcG9lLQ0KPiBoZWFsdGgt MDEudHh0DQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXBhdHRlcnNvbi1pbnRhcmVhLWlw b2UtaGVhbHRoIGhhcyBiZWVuIHBvc3RlZC4NCj4gDQo+IFRoZSBtYWpvciBjaGFuZ2Ugc2luY2Ug LTAwLCBpcyB0aGUgaW5jbHVzaW9uIGFuZCBwcmVmZXJlbmNlIG9mIEJGRA0KPiBFY2hvIGFzIHRo ZSBoZWFsdGggY2hlY2sgbWVjaGFuaXNtIHdoZW4gYXZhaWxhYmxlLg0KPiBUaGUgZHJhZnQgbm93 IGhhcyBhbiBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSB0byBCcm9hZGJhbmQgRm9ydW0ncw0KPiBU Ui0xNDYgZG9jdW1lbnQgd2hpY2ggYWxzbyBkaXNjdXNzZXMgdGhpcyBwcm9ibGVtLg0KPiANCj4g VGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgYnVpbGRzIG9uIHRoZSBtZXRob2Qg c3VnZ2VzdGVkIGluDQo+IFRSLTE0NiBpbiB0aGUgZm9sbG93aW5nIHdheXM6DQo+IC0gUHJlZmVy cyBCRkQgRWNobywgYnV0IGFsbG93cyBmb3IgQVJQL05EIG1ldGhvZHMgd2hlbiBub3QgYXZhaWxh YmxlLg0KPiAtIERlZmF1bHRzIHRvIERIQ1AgcmVuZXcgYXMgYW4gYWN0aW9uLCBidXQgc3BlY2lm aWVzIG9wdGlvbmFsDQo+IGFsdGVybmF0aXZlIGFjdGlvbnMgdG8gZXhwZWRpdGUgcmVjb3Zlcnku DQo+IC0gUHJvdmlkZXMgYSBESENQIE9wdGlvbiB0byBhbGxvdyBuZXR3b3JrIGFkbWluaXN0cmF0 b3JzIHRvIHNpZ25hbA0KPiBwYXJhbWV0ZXJzIGR5bmFtaWNhbGx5IHRvIENFcy4NCj4gDQo+IA0K PiDvu79PbiAxMi8wNi8yMDE4LCAxMDoxMSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyINCj4g PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiANCj4gICAgIEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1wYXR0ZXJzb24taW50YXJlYS1pcG9lLWhlYWx0aC0wMS50eHQN Cj4gICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmljaGFyZCBQYXR0ZXJz b24gYW5kIHBvc3RlZCB0byB0aGUNCj4gICAgIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+ICAgICBO YW1lOmRyYWZ0LXBhdHRlcnNvbi1pbnRhcmVhLWlwb2UtaGVhbHRoDQo+ICAgICBSZXZpc2lvbjow MQ0KPiAgICAgVGl0bGU6SVBvRSBDbGllbnQgSGVhbHRoIENoZWNraW5nDQo+ICAgICBEb2N1bWVu dCBkYXRlOjIwMTgtMDYtMTINCj4gICAgIEdyb3VwOkluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiAg ICAgUGFnZXM6MTINCj4gICAgIFVSTDoNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRz X2RyYWZ0LTJEcGF0dGVyc29uLTJEaW50YXJlYS0yRGlwb2UtDQo+IDJEaGVhbHRoLQ0KPiAyRDAx LnR4dCZkPUR3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYz aUMNCj4gcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUVCZHhNTUNCXzNiaFJ4N01rNVJob2JM UHV4Z0RuDQo+IG1iVTZWU2pwTjRnMUJZJnM9YmpCdTl2N0FVRllQS25XbGNiTWNwVkFVQ0JBUUFR a2phcnJaMHJBQVVNDQo+IHMmZT0NCj4gICAgIFN0YXR1czoNCj4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5v cmdfZG9jX2RyYWZ0LTJEcGF0dGVyc29uLTJEaW50YXJlYS0yRGlwb2UtDQo+IDJEaGVhbHRoXyZk PUR3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzDQo+IGlD cmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUVCZHhNTUNCXzNiaFJ4N01rNVJob2JMUHV4Z0QN Cj4gbm1iVTZWU2pwTjRnMUJZJnM9ZHB4eXlQQm9PNEE2QkV1dGcwS2FUVDJxMVBGV1NVZDl4c2pP UHFlbDU4cw0KPiAmZT0NCj4gICAgIEh0bWxpemVkOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX190b29scy5pZXRmLm9yZ19odG1sX2Ry YWZ0LTJEcGF0dGVyc29uLTJEaW50YXJlYS0yRGlwb2UtMkRoZWFsdGgtDQo+IDJEMDEmZD1Ed0lH YVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJDQo+IG9V V0I4WUxaVTIzMDI5c01RR1Eya1kmbT1FQmR4TU1DQl8zYmhSeDdNazVSaG9iTFB1eGdEbm1iDQo+ IFU2VlNqcE40ZzFCWSZzPVRoRWtuVjVkR1dEMmRXalBpdDlVY1IwelRSZVNMYl9IRGJoREZONlN5 Q1UmZQ0KPiA9DQo+ICAgICBIdG1saXplZDoNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0 bWxfZHJhZnQtMkRwYXR0ZXJzb24tMkRpbnRhcmVhLTJEaXBvZS0NCj4gMkRoZWFsdGgmZD1Ed0lH YVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2kNCj4gQ3JoSW9V V0I4WUxaVTIzMDI5c01RR1Eya1kmbT1FQmR4TU1DQl8zYmhSeDdNazVSaG9iTFB1eGdEDQo+IG5t YlU2VlNqcE40ZzFCWSZzPXdMM0N1dHJqemZ5eDVTTHBNOHFWekc0RkhQeFpvVWtxenJpRUxuM2t1 TE0mDQo+IGU9DQo+ICAgICBEaWZmOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDItM0Rk cmFmdC0yRHBhdHRlcnNvbi0yRGludGFyZWEtMkRpcG9lLQ0KPiAyRGhlYWx0aC0NCj4gMkQwMSZk PUR3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaEkN Cj4gb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUVCZHhNTUNCXzNiaFJ4N01rNVJob2JMUHV4Z0Ru bWINCj4gVTZWU2pwTjRnMUJZJnM9Y3hjWjB0cERCUlpjMWlYU0lLRTlyaUtZLWQ2dU1vU2hBc1V2 dFB4RlZURSZlPQ0KPiANCj4gICAgIEFic3RyYWN0Og0KPiAgICAgICAgUFBQIG92ZXIgRXRoZXJu ZXQgY2xpZW50cyBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBwYXRoDQo+ICAgICAg ICB1bmF2YWlsYWJpbGl0eSBieSB1c2luZyBQUFAgS2VlcGFsaXZlcy4gIElQIG92ZXIgRXRoZXJu ZXQgZG9lcyBub3QNCj4gICAgICAgIGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5LCBhbmQgaXQncyBu b3Qgc3BlY2lmaWVkIHdoZW4gYW4gSVAgb3Zlcg0KPiAgICAgICAgRXRoZXJuZXQgY2xpZW50IHNo b3VsZCBjb25zaWRlciBpdHMgV0FOIGNvbm5lY3Rpdml0eSBkb3duLCB1bmxlc3MNCj4gICAgICAg IHRoZXJlIGlzIGEgcGh5c2ljYWwgbGF5ZXIgbGluayBkb3duIGV2ZW50Lg0KPiANCj4gICAgICAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgd2F5IGZvciBJUCBvdmVyIEV0aGVybmV0IGNsaWVu dHMgdG8gYWNoaWV2ZQ0KPiAgICAgICAgY29ubmVjdGl2aXR5IHZhbGlkYXRpb24sIHNpbWlsYXIg dG8gdGhhdCBvZiBQUFAgb3ZlciBFdGhlcm5ldCwgYnkNCj4gICAgICAgIHVzaW5nIEJGRCBFY2hv LCBvciBBUlAgYW5kIE5laWdoYm9yIERpc2NvdmVyeSBmdW5jdGlvbnMuDQo+IA0KPiANCj4gDQo+ IA0KPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiAgICAgdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ ICAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGll dGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9 QkZwV1F3OGJzdUtwDQo+IGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlM WlUyMzAyOXNNUUdRMmtZJm09RUJkDQo+IHhNTUNCXzNiaFJ4N01rNVJob2JMUHV4Z0RubWJVNlZT anBONGcxQlkmcz1nZVJQWHREaUdhalJqcWIzMQ0KPiBIUmpwMWxlM3pyZmxZank2eWhYUERTQm91 YyZlPQ0K From nobody Tue Jun 12 08:32: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 62A34124C04 for ; Tue, 12 Jun 2018 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAt9CqW5zUvi for ; Tue, 12 Jun 2018 08:32:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34846130E54 for ; Tue, 12 Jun 2018 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8676; q=dns/txt; s=iport; t=1528817532; x=1530027132; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5cKFvaMbJo4xLiCEeYHCffGz5pMaHat8QoyDnieIL0s=; b=fcyUmGGWIERLRIiTM5WA6aMpJHHWWYJ9jlLCbbBDwz05tVawgQdYu3wh Plr4St8D6hqlYKhmy4LebTxMw/EHv3IShjBCzXqRoYPvrvrfOwQvndvH/ b84UMrYgGHIZegF2yDsD1aU7mygjcBc9xOzQsuAUQwqVB6dO7waytoZ7L s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAAAX5x9b/5ldJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYn8oCoNtiASMaIFeIZRbgXgLGAuESQIXghshNBgBAgE?= =?us-ascii?q?BAQEBAQJtHAyFKAEBAQEDAQEhEToJDgQCAQgRBAEBAQICIwMCAgIlCxQBCAg?= =?us-ascii?q?CBAESgyICgX8PqnKCHIhHgWiBC4c9ghOBDyQMglyDEQEBAgEXgTAWF4JpMYI?= =?us-ascii?q?kAow2hQCHUAkChXGJBoE/QYM9h3WKCYcIAhETAYEkHTiBUnAVGiEqAYIYCYI?= =?us-ascii?q?TLYM0hRSFPm+NUCuBAYEaAQE?= X-IronPort-AV: E=Sophos;i="5.51,215,1526342400"; d="scan'208";a="407252865" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 15:31:57 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w5CFVvjh022037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2018 15:31:57 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Jun 2018 10:31:56 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Tue, 12 Jun 2018 10:31:56 -0500 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" , Richard Patterson , "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt Thread-Index: AQHUAj4k3JEcdK9gAkWXGzYu/zb6qqRdDTwA///EBAA= Date: Tue, 12 Jun 2018 15:31:56 +0000 Message-ID: <2E94C78D-DC5E-4862-A493-A8E56A949FA2@cisco.com> References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.95] Content-Type: text/plain; charset="utf-8" Content-ID: <933F31240768A043B9ED5681FC04D3CA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 15:32:21 -0000 PiAgICAtIElmIHllcywgaXMgREhDUHY2IGNsaWVudCBnb2luZyB0byBzZW5kIHRoZSBzYW1lIGFk ZHJlc3MgaW4gU09MSUNJVD8gSXMgREhDUHY2IGNsaWVudCBnb2luZyB0byB1bmljYXN0IFNPTElD SVQgdG8gdGhlIHNhbWUgREhDUHY2IHNlcnZlciwgaWYgT1BUSU9OX1VOSUNBU1Qgd2FzIHNldCBm b3IgdGhlIGxlYXNlPw0KIA0KU09MSUNJVHMgbXVzdCBub3QgYmUgdW5pY2FzdC4NCg0KU2VlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTEzI3Nl Y3Rpb24tMTY6DQoNCiAgIEEgc2VydmVyIE1VU1QgZGlzY2FyZCBhbnkgU29saWNpdCwgQ29uZmly bSwgUmViaW5kIG9yIEluZm9ybWF0aW9uLQ0KICAgcmVxdWVzdCBtZXNzYWdlcyBpdCByZWNlaXZl cyB3aXRoIGEgbGF5ZXItMyB1bmljYXN0IGRlc3RpbmF0aW9uDQogICBhZGRyZXNzLg0KDQpBIGNs aWVudCBjYW4gY2VydGFpbmx5IGluY2x1ZGUgdGhlIGFkZHJlc3MgaXQgcHJldmlvdXNseSBoYWQg aW4gYSBTb2xpY2l0ICh0aG91Z2ggbW9zdCBsaWtlbHkgaWYgdGhlIHNhbWUgc2VydmVyIGlzIHBy ZXNlbnQsIHRoYXQgaXMgbm90IG5lY2Vzc2FyeSBhcyB0aGUgc2VydmVyIHdpbGwgbGlrZWx5IHVz ZSB0aGUgZXhpc3RpbmcgYWRkcmVzcykuIFRoZXJlIGFyZSBhbHNvIHByaXZhY3kgY29uc2lkZXJh dGlvbnMgZm9yIGluY2x1ZGluZyB0aGlzIGluIHRoZSBTb2xpY2l0IChzaW5jZSB0aGUgY2xpZW50 IG1heSBoYXZlIG1vdmVkIHRvIGEgZGlmZmVyZW50IG5ldHdvcmspLg0KDQotIEJlcm5pZQ0KDQpP biA2LzEyLzE4LCAxMTowNiBBTSwgInY2b3BzIG9uIGJlaGFsZiBvZiBNdWRyaWMsIER1c2FuIChE dXNhbikiIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBkbXVkcmljQGF2YXlh LmNvbT4gd3JvdGU6DQoNCiAgICBIaSBSaWNoYXJkLA0KICAgIA0KICAgICI0LjMuICBCZWhhdmlv dXIgMjogRXhwaXJlIExlYXNlIg0KICAgIA0KICAgIFR5cG86IEJlaGF2aW9yDQogICAgDQogICAg LSBJcyB0aGlzIG9wdGlvbiBhbiBhdHRlbXB0IGZvciB0aGUgbGVhc2UgUkVORVctYWwgYnV0IG5v dCB1c2luZyBSRU5FVz8NCiAgICAtIElmIG5vdCwgd2hhdCBpcyB0aGUgYmVuZWZpdCBvZiBub3Qg c2VuZGluZyBSRUxFQVNFPyANCiAgICAtIElmIHllcywgaXMgREhDUHY2IGNsaWVudCBnb2luZyB0 byBzZW5kIHRoZSBzYW1lIGFkZHJlc3MgaW4gU09MSUNJVD8gSXMgREhDUHY2IGNsaWVudCBnb2lu ZyB0byB1bmljYXN0IFNPTElDSVQgdG8gdGhlIHNhbWUgREhDUHY2IHNlcnZlciwgaWYgT1BUSU9O X1VOSUNBU1Qgd2FzIHNldCBmb3IgdGhlIGxlYXNlPw0KICAgIA0KICAgIFRoYW5rcywNCiAgICBE dXNhbi4NCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9t OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNo YXJkDQogICAgPiBQYXR0ZXJzb24NCiAgICA+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTgg NzoxMSBBTQ0KICAgID4gVG86IHY2b3BzQGlldGYub3JnIGxpc3QgPHY2b3BzQGlldGYub3JnPg0K ICAgID4gU3ViamVjdDogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXBhdHRlcnNvbi1pbnRhcmVhLWlwb2UtDQogICAgPiBoZWFsdGgtMDEudHh0DQogICAgPiANCiAg ICA+IEEgbmV3IHZlcnNpb24gb2YgZHJhZnQtcGF0dGVyc29uLWludGFyZWEtaXBvZS1oZWFsdGgg aGFzIGJlZW4gcG9zdGVkLg0KICAgID4gDQogICAgPiBUaGUgbWFqb3IgY2hhbmdlIHNpbmNlIC0w MCwgaXMgdGhlIGluY2x1c2lvbiBhbmQgcHJlZmVyZW5jZSBvZiBCRkQNCiAgICA+IEVjaG8gYXMg dGhlIGhlYWx0aCBjaGVjayBtZWNoYW5pc20gd2hlbiBhdmFpbGFibGUuDQogICAgPiBUaGUgZHJh ZnQgbm93IGhhcyBhbiBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSB0byBCcm9hZGJhbmQgRm9ydW0n cw0KICAgID4gVFItMTQ2IGRvY3VtZW50IHdoaWNoIGFsc28gZGlzY3Vzc2VzIHRoaXMgcHJvYmxl bS4NCiAgICA+IA0KICAgID4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgYnVp bGRzIG9uIHRoZSBtZXRob2Qgc3VnZ2VzdGVkIGluDQogICAgPiBUUi0xNDYgaW4gdGhlIGZvbGxv d2luZyB3YXlzOg0KICAgID4gLSBQcmVmZXJzIEJGRCBFY2hvLCBidXQgYWxsb3dzIGZvciBBUlAv TkQgbWV0aG9kcyB3aGVuIG5vdCBhdmFpbGFibGUuDQogICAgPiAtIERlZmF1bHRzIHRvIERIQ1Ag cmVuZXcgYXMgYW4gYWN0aW9uLCBidXQgc3BlY2lmaWVzIG9wdGlvbmFsDQogICAgPiBhbHRlcm5h dGl2ZSBhY3Rpb25zIHRvIGV4cGVkaXRlIHJlY292ZXJ5Lg0KICAgID4gLSBQcm92aWRlcyBhIERI Q1AgT3B0aW9uIHRvIGFsbG93IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdG8gc2lnbmFsDQogICAg PiBwYXJhbWV0ZXJzIGR5bmFtaWNhbGx5IHRvIENFcy4NCiAgICA+IA0KICAgID4gDQogICAgPiBP biAxMi8wNi8yMDE4LCAxMDoxMSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyINCiAgICA+IDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+ICAg ICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcGF0dGVyc29uLWludGFyZWEtaXBvZS1oZWFs dGgtMDEudHh0DQogICAgPiAgICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBS aWNoYXJkIFBhdHRlcnNvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgID4gICAgIElFVEYgcmVwb3Np dG9yeS4NCiAgICA+IA0KICAgID4gICAgIE5hbWU6ZHJhZnQtcGF0dGVyc29uLWludGFyZWEtaXBv ZS1oZWFsdGgNCiAgICA+ICAgICBSZXZpc2lvbjowMQ0KICAgID4gICAgIFRpdGxlOklQb0UgQ2xp ZW50IEhlYWx0aCBDaGVja2luZw0KICAgID4gICAgIERvY3VtZW50IGRhdGU6MjAxOC0wNi0xMg0K ICAgID4gICAgIEdyb3VwOkluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgID4gICAgIFBhZ2VzOjEy DQogICAgPiAgICAgVVJMOg0KICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLQ0KICAgID4gM0FfX3d3dy5pZXRmLm9yZ19pbnRlcm5ldC0yRGRyYWZ0 c19kcmFmdC0yRHBhdHRlcnNvbi0yRGludGFyZWEtMkRpcG9lLQ0KICAgID4gMkRoZWFsdGgtDQog ICAgPiAyRDAxLnR4dCZkPUR3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazlj YkxlYUp4aGYzaUMNCiAgICA+IHJoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1FQmR4TU1DQl8z YmhSeDdNazVSaG9iTFB1eGdEbg0KICAgID4gbWJVNlZTanBONGcxQlkmcz1iakJ1OXY3QVVGWVBL bldsY2JNY3BWQVVDQkFRQVFramFyclowckFBVU0NCiAgICA+IHMmZT0NCiAgICA+ICAgICBTdGF0 dXM6DQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtDQogICAgPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEcGF0dGVyc29u LTJEaW50YXJlYS0yRGlwb2UtDQogICAgPiAyRGhlYWx0aF8mZD1Ed0lHYVEmYz1CRnBXUXc4YnN1 S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmMw0KICAgID4gaUNyaElvVVdCOFlMWlUyMzAy OXNNUUdRMmtZJm09RUJkeE1NQ0JfM2JoUng3TWs1UmhvYkxQdXhnRA0KICAgID4gbm1iVTZWU2pw TjRnMUJZJnM9ZHB4eXlQQm9PNEE2QkV1dGcwS2FUVDJxMVBGV1NVZDl4c2pPUHFlbDU4cw0KICAg ID4gJmU9DQogICAgPiAgICAgSHRtbGl6ZWQ6DQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQogICAgPiAzQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9kcmFmdC0yRHBhdHRlcnNvbi0yRGludGFyZWEtMkRpcG9lLTJEaGVhbHRoLQ0KICAgID4gMkQw MSZkPUR3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNy aEkNCiAgICA+IG9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1FQmR4TU1DQl8zYmhSeDdNazVSaG9i TFB1eGdEbm1iDQogICAgPiBVNlZTanBONGcxQlkmcz1UaEVrblY1ZEdXRDJkV2pQaXQ5VWNSMHpU UmVTTGJfSERiaERGTjZTeUNVJmUNCiAgICA+ID0NCiAgICA+ICAgICBIdG1saXplZDoNCiAgICA+ IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCiAgICA+ IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRHBhdHRlcnNvbi0yRGlu dGFyZWEtMkRpcG9lLQ0KICAgID4gMkRoZWFsdGgmZD1Ed0lHYVEmYz1CRnBXUXc4YnN1S3BsMVNn aVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2kNCiAgICA+IENyaElvVVdCOFlMWlUyMzAyOXNNUUdR MmtZJm09RUJkeE1NQ0JfM2JoUng3TWs1UmhvYkxQdXhnRA0KICAgID4gbm1iVTZWU2pwTjRnMUJZ JnM9d0wzQ3V0cmp6Znl4NVNMcE04cVZ6RzRGSFB4Wm9Va3F6cmlFTG4za3VMTSYNCiAgICA+IGU9 DQogICAgPiAgICAgRGlmZjoNCiAgICA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0NCiAgICA+IDNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDIt M0RkcmFmdC0yRHBhdHRlcnNvbi0yRGludGFyZWEtMkRpcG9lLQ0KICAgID4gMkRoZWFsdGgtDQog ICAgPiAyRDAxJmQ9RHdJR2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVh SnhoZjNpQ3JoSQ0KICAgID4gb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUVCZHhNTUNCXzNiaFJ4 N01rNVJob2JMUHV4Z0RubWINCiAgICA+IFU2VlNqcE40ZzFCWSZzPWN4Y1owdHBEQlJaYzFpWFNJ S0U5cmlLWS1kNnVNb1NoQXNVdnRQeEZWVEUmZT0NCiAgICA+IA0KICAgID4gICAgIEFic3RyYWN0 Og0KICAgID4gICAgICAgIFBQUCBvdmVyIEV0aGVybmV0IGNsaWVudHMgaGF2ZSB0aGUgZnVuY3Rp b25hbGl0eSB0byBkZXRlY3QgcGF0aA0KICAgID4gICAgICAgIHVuYXZhaWxhYmlsaXR5IGJ5IHVz aW5nIFBQUCBLZWVwYWxpdmVzLiAgSVAgb3ZlciBFdGhlcm5ldCBkb2VzIG5vdA0KICAgID4gICAg ICAgIGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5LCBhbmQgaXQncyBub3Qgc3BlY2lmaWVkIHdoZW4g YW4gSVAgb3Zlcg0KICAgID4gICAgICAgIEV0aGVybmV0IGNsaWVudCBzaG91bGQgY29uc2lkZXIg aXRzIFdBTiBjb25uZWN0aXZpdHkgZG93biwgdW5sZXNzDQogICAgPiAgICAgICAgdGhlcmUgaXMg YSBwaHlzaWNhbCBsYXllciBsaW5rIGRvd24gZXZlbnQuDQogICAgPiANCiAgICA+ICAgICAgICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHdheSBmb3IgSVAgb3ZlciBFdGhlcm5ldCBjbGllbnRz IHRvIGFjaGlldmUNCiAgICA+ICAgICAgICBjb25uZWN0aXZpdHkgdmFsaWRhdGlvbiwgc2ltaWxh ciB0byB0aGF0IG9mIFBQUCBvdmVyIEV0aGVybmV0LCBieQ0KICAgID4gICAgICAgIHVzaW5nIEJG RCBFY2hvLCBvciBBUlAgYW5kIE5laWdoYm9yIERpc2NvdmVyeSBmdW5jdGlvbnMuDQogICAgPiAN CiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KICAgID4gc3VibWlz c2lvbg0KICAgID4gICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+ICAgICBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4gdjZvcHMgbWFpbGluZyBsaXN0DQogICAgPiB2Nm9wc0Bp ZXRmLm9yZw0KICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLQ0KICAgID4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9 RHdJR2FRJmM9QkZwV1F3OGJzdUtwDQogICAgPiBsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhm M2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUVCZA0KICAgID4geE1NQ0JfM2JoUng3TWs1 UmhvYkxQdXhnRG5tYlU2VlNqcE40ZzFCWSZzPWdlUlBYdERpR2FqUmpxYjMxDQogICAgPiBIUmpw MWxlM3pyZmxZank2eWhYUERTQm91YyZlPQ0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNA aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQogICAgDQoNCg== From nobody Tue Jun 12 08:41: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 0B02C130E61 for ; Tue, 12 Jun 2018 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvUq3Sp2Kzzs for ; Tue, 12 Jun 2018 08:41:34 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 52196130E62 for ; Tue, 12 Jun 2018 08:41:34 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id l6-v6so16027253iti.2 for ; Tue, 12 Jun 2018 08:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L9H8nX0lMv59TJgVDnxTSmUXGptLbERUf7tb4uvIVUg=; b=RNioI1MMPTC0osIyDYMl7+6uKeMe+SaJM23pDHZhs3ksjGEfs713QcW3dd/6/Ohngo pST6OViyjUBRJmfateJATyPZWB4bTPEF3sxGuroapK177MHp1muLteDbRch1c4cdVUie HvtILgS2Us3+d9X3zNgaJE+UNsIMmXCLGQTfVhUdcWkA9vC+PaSJ2V6mCnU0FEsM2lKx svVx2xej0CFZULvhc0KLNl1ujn8198e14h1NGM78ZyMD8kKtu4icPo4JRQdPiQL6UGZX ZRH7p+ZJGqj2lc0GLaickdJV3RhqupkwOsl5ZXG5q+JBjvry0CE6SzNzlBlh1DFd7Nb7 gQNQ== 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=L9H8nX0lMv59TJgVDnxTSmUXGptLbERUf7tb4uvIVUg=; b=RQS6+3eh3E54a9xb/KggY5gBwLJENXu2myGa+hj9nn5TPIS9Fm/zVvcSvNQ0QNCJIH 6i6f0Zj4hyQOUbkE/dvh/Hg6CBmQ9sezSPXiMuwc3PEQ9CIO4MWT2bdPxor/CTTlce2w cVnnY3LM40F9sjA4denbDQrcyHzYBUp2lL3NkZV08IDIy1zosSWAvdAxt9cUTRDDlrdw R7hWRCGUAA9AwJQhx+tC4aLLS+AiyCQVvXrh1SeM0r4cTUPtdMp3INN7u3EuCmGOFo7S iEJzoKTxZwnHWhI4Ubw3+fVvC0PkpvPdalp2yYThpAZl1rbNxq+N5zemOtWJQadQeeaE diJQ== X-Gm-Message-State: APt69E3fe7z4dUm+9zNvi38Y0JREow2cxIEUd6XoZ0JgYpHNDP44JTWj SdSwTRx7BRL5bL4bSa+BMJ8wjR7QbILW5lcUEVw= X-Google-Smtp-Source: ADUXVKLGcQtz5qRoSzPICghAV5ExboKIbs32lVcAEt7c6ePf3PDql8GXiD6N1nd38YtUnvrf9sHd5Ss323FU06kkXZc= X-Received: by 2002:a24:7809:: with SMTP id p9-v6mr950536itc.20.1528818093559; Tue, 12 Jun 2018 08:41:33 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 2002:a4f:4f4f:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 08:41:33 -0700 (PDT) In-Reply-To: <727eaf16c964422da8b2ffbf2bf8c6c0@XCH15-06-08.nw.nos.boeing.com> References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> <727eaf16c964422da8b2ffbf2bf8c6c0@XCH15-06-08.nw.nos.boeing.com> From: Erik Nygren Date: Tue, 12 Jun 2018 11:41:33 -0400 X-Google-Sender-Auth: wgT-bjCHo-CF0czwXzFMsUL-DLg Message-ID: To: "Templin (US), Fred L" Cc: Fred Baker , "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000649817056e73b307" Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 15:41:37 -0000 --000000000000649817056e73b307 Content-Type: text/plain; charset="UTF-8" I'm also supportive of the WG taking this on and discussing on the agenda in IETF102. On Mon, Jun 11, 2018 at 3:48 PM, Templin (US), Fred L < Fred.L.Templin@boeing.com> wrote: > Hi Fred, > > There was a similar question back in the March 2018 timeframe, and there > were > several responses in support. The document was then presented remotely at > IETF101, but there was no time left over for questions afterwards. > > I am planning to attend IETF102 in person, so would be better able to > interact > and get a sense of the room. > > Thanks - Fred > > > -----Original Message----- > > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > > Sent: Monday, June 11, 2018 11:47 AM > > To: Templin (US), Fred L > > Cc: v6ops@ietf.org list > > Subject: Re: [v6ops] IETF 102 Agenda > > > > On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L < > Fred.L.Templin@boeing.com> wrote: > > > Hi Fred, > > > > > > 'draft-templin-v6ops-pdhost' has been updated, and received list > traffic both > > > before and after the update was posted. Please add to the agenda. > > > > > > Thanks - Fred > > > > Hi. I'm looking at the discussion post-IETF-101, and looking for someone > saying "I support this draft. I think it describes something I > > want to deploy in my network." This is an operational working group; I'm > looking especially for comments from network operators. > > This is a discussion you and I have had a number of times. What the > chairs want to give agenda time to is drafts that the working group > > participants find useful and interesting. We gauge that from list > discussion. So it's not "number of comments, when comments are > > specifically solicited, exceed zero", but "someone said it was useful > and interesting in their deployment". > > > > Since IETF 101, we have had two threads on the subject of pdhost. I > initiated "let's discuss this" in late April: > > https://www.ietf.org/mail-archive/web/v6ops/current/msg29222.html. > > > > In that thread, we had comments from > > - Dusan Medric, who wondered whether there was a discussion of > allocating a prefix (such as a /64) to a host, > > - Joe Touch, Mark Smith, and Ole Troan regarding the distinction a > "weak" and a "strong" host and between a "platform", a "router", > > a "host", and a "node", and > > - Alexandre Petrescu, on the utility in his IOT MIPv6 network. > > > > I initiated another after your update on 29 May ( > https://www.ietf.org/mail-archive/web/v6ops/current/msg29275.html). In > that, you > > and Alexandre Petrescu discussed the utility of this in his IOT > environment, in which he wanted to use RFC 3633 to delegate a prefix to > > an IOT router for use in an enclave in his network. You and he disagreed > on what was to be done with the delegated prefix. > > > > I'm still looking for a comment from a working group participant saying > s/he finds draft-templin-v6ops-pdhost, in its 21st revision, > > "useful and interesting". What I see is 14 emails since IETF 101, many > of which you responded to, from people who fundamentally > > disagreed with you on one point or another. > > > > General comment to those on the CC line: if this draft describes > something useful to you in your network, your comment can > > dramatically change the conversation between Fred and myself. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000649817056e73b307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm also supportive of the WG taking this on and discu= ssing on the agenda in IETF102.

On Mon, Jun 11, 2018 at 3:48 PM, Templin (US), Fred= L <Fred.L.Templin@boeing.com> wrote:
Hi Fred,

There was a similar question back in the March 2018 timeframe, and there we= re
several responses in support. The document was then presented remotely at IETF101, but there was no time left over for questions afterwards.

I am planning to attend IETF102 in person, so would be better able to inter= act
and get=C2=A0 a sense of the room.

Thanks - Fred

> -----Original Message-----
> From: Fred Baker [mailt= o:fredbaker.ietf@gmail.com= ]
> Sent: Monday, June 11, 2018 11:47 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: v6ops@ietf.org list <v6ops@ietf.org>
> Subject: Re: [v6ops] IETF 102 Agenda
>
> On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > Hi Fred,
> >
> > 'draft-templin-v6ops-pdhost' has been updated, and receiv= ed list traffic both
> > before and after the update was posted. Please add to the agenda.=
> >
> > Thanks - Fred
>
> Hi. I'm looking at the discussion post-IETF-101, and looking for s= omeone saying "I support this draft. I think it describes something I<= br> > want to deploy in my network." This is an operational working gro= up; I'm looking especially for comments from network operators.
> This is a discussion you and I have had a number of times. What the ch= airs want to give agenda time to is drafts that the working group
> participants find useful and interesting. We gauge that from list disc= ussion. So it's not "number of comments, when comments are
> specifically solicited, exceed zero", but "someone said it w= as useful and interesting in their deployment".
>
> Since IETF 101, we have had two threads on the subject of pdhost. I in= itiated "let's discuss this" in late April:
> https://www.ietf.org/mail-archive/web/v6ops/current/msg29222.html.
>
> In that thread, we had comments from
>=C2=A0 =C2=A0- Dusan Medric, who wondered whether there was a discussio= n of allocating a prefix (such as a /64) to a host,
>=C2=A0 =C2=A0- Joe Touch, Mark Smith, and Ole Troan regarding the disti= nction a "weak" and a "strong" host and between a "= ;platform", a "router",
> a "host", and a "node", and
>=C2=A0 =C2=A0- Alexandre Petrescu, on the utility in his IOT MIPv6 netw= ork.
>
> I initiated another after your update on 29 May (https://www.ietf.org/mail-archive/web/v6ops/current= /msg29275.html). In that, you
> and Alexandre Petrescu discussed the utility of this in his IOT enviro= nment, in which he wanted to use RFC 3633 to delegate a prefix to
> an IOT router for use in an enclave in his network. You and he disagre= ed on what was to be done with the delegated prefix.
>
> I'm still looking for a comment from a working group participant s= aying s/he finds draft-templin-v6ops-pdhost, in its 21st revision,
> "useful and interesting". What I see is 14 emails since IETF= 101, many of which you responded to, from people who fundamentally
> disagreed with you on one point or another.
>
> General comment to those on the CC line: if this draft describes somet= hing useful to you in your network, your comment can
> dramatically change the conversation between Fred and myself.

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

--000000000000649817056e73b307-- From nobody Tue Jun 12 08:57: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 14DD9130E84 for ; Tue, 12 Jun 2018 08:57:48 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 3nOgImmxVwcF for ; Tue, 12 Jun 2018 08:57:41 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA65130E62 for ; Tue, 12 Jun 2018 08:57:40 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id s26-v6so28668653ioj.4 for ; Tue, 12 Jun 2018 08:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rbqJ5E4gTJLQwnft0zJbR7zgpQcWJWeUE9RPLZuYSbg=; b=byaIutno3UV0WiLjjyaDCUmBZunUSmZGNSwjqfD7HxePZ26yhMpVmlXvqSJzAC7flz VjB/Q3K1P3reXzSfZFvu3fo9JVWctojxT0kF+Jt3YYPpw4SLvHJwOFX+jqXl2Iqk4DkZ DszZJp9fH0gmRzG3xs8dp9tzh1AFceIRBV2CkH6cTU9HNpPW9D56YktfGssfHMuw8bv2 RHfF5+mAJCeXnOa24H1kuB2Sfu1r7WmXAgEM4zxCkL/is6NjJ9zviyt8LyAQEhnCBrw+ dhxAf7MaQoc2Hf1++LMQqhlWDs4urNZogQzqDK0hPj+0GPV+PBci7pdF37yw9z0ea4BA Jk2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rbqJ5E4gTJLQwnft0zJbR7zgpQcWJWeUE9RPLZuYSbg=; b=K7NOZxf2f+VFv5sAEqhtn10mpTrLDu6SczsVhCt+kTN/lTrnK/oae7VY12wEqsqwZj QZ57jFQFJ0y+x140QcRdmPwatV8dy36dgLw6GKP9mpIZUzpTJJo0ldzWLBMXyBCR2OsM spiOKpo2Y2ZMpnAP8yo3OyopbZnEiLSHpQ7rXT9Y+ucyvG0wVzqGQl5fgm7dU/7rIAdk iwSBejQASy9NEScbL8LS5/+RJRwdgknlYsPEFy+yaVDcxUIN847p32F2e5YKj5Dzwn94 mGPj0BHb79HqbzpRqs+V2DP/Dcz/yfeNgSl5tQZnyHK/4XymJXCPOXGs+EG35N7BFY5w HF0Q== X-Gm-Message-State: APt69E3cRO8WBNGT0yewbGOFUckOkaLNWv50kh9wOWMREGjVFC7moPNA CfENMLVFM0xafBBC6NVcj9ssyUWW X-Google-Smtp-Source: ADUXVKLz6ud5ecwi4WZpXjHFmcIUANC/MJuFzJrYVMShPDj/oWVrGLzOX4OGAlbB7t+eM67fWlL5ig== X-Received: by 2002:a6b:c544:: with SMTP id v65-v6mr1043508iof.278.1528819060206; Tue, 12 Jun 2018 08:57:40 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id 77-v6sm458555itm.36.2018.06.12.08.57.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 08:57:39 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id y127-v6so14555235itd.1 for ; Tue, 12 Jun 2018 08:57:39 -0700 (PDT) X-Received: by 2002:a24:8046:: with SMTP id g67-v6mr1033135itd.16.1528819059525; Tue, 12 Jun 2018 08:57:39 -0700 (PDT) MIME-Version: 1.0 References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> From: Richard Patterson Date: Tue, 12 Jun 2018 16:57:28 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , dmudric@avaya.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 15:57:48 -0000 Hi Dusan, Thanks for the review, responses in-line: On Tue, 12 Jun 2018 at 16:07, Mudric, Dusan (Dusan) wrote: > > Hi Richard, > > "4.3. Behaviour 2: Expire Lease" > > Typo: Behavior [RP] Isn't British spelling accepted as long as it's consistent throughout the document? I can s/behaviour/behavior/ if required. > - Is this option an attempt for the lease RENEW-al but not using RENEW? [RP] This action is for when the subscriber state in the network has been lost, regular RENEWs will likely be dropped by the network, until the network can authenticate the IPoE Client again, which is usually done based on a DHCPv4 DISCOVER or DHCPv6 SOLICIT. > - If not, what is the benefit of not sending RELEASE? [RP] A Release instructs the DHCP server to relinquish the lease entirely. Avoiding this step allows a client to potentially rebind the previously leased IP/prefix, which can reduce the customer experience impact when operating with dynamic leases. > - If yes, is DHCPv6 client going to send the same address in SOLICIT? Is DHCPv6 client going to unicast SOLICIT to the same DHCPv6 server, if OPTION_UNICAST was set for the lease? [RP] This document relies on existing DHCP messaging, and we don't want to adjust that behaviour. I don't believe anything in 3315 specifies that a SOLICIT could be unicast following a lease expiration? I believe OPTION_UNICAST is for just in-life messaging as opposed to server discovery, but I could be wrong. The client can include the previously leased prefix in the REQUEST, the server may accept it if it's available, or NAK it. To simplify adoption we've attempted to reuse existing functionality where possible, hence the use or ARP/ND and just adjusting the T1/T2 timers to trigger the usual DHCP processes. Given the above, Dusan, do you think the wording in the draft needs clarification? -Richard From nobody Tue Jun 12 11:27: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 94129130FAB for ; Tue, 12 Jun 2018 11:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 PTE8BGkQpwE1 for ; Tue, 12 Jun 2018 11:27:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D50130FA5 for ; Tue, 12 Jun 2018 11:27:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G/AADYDyBb/yYyC4dcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJwU4FPEigKg26IBIxpgX+UW4F4CyyEQAIXghwhNBgBAgEBAQE?= =?us-ascii?q?BAQICAmkohSoBAQEBAgESERFDBwcEAgEIDQQEAQEBAgIGHQMCAgIwFAEICAIEA?= =?us-ascii?q?RIIEQmEeQgBoU6JbIIcGgKILYFogQuHPYFVPoQbhF0YFYJqMYIkAodSkTQJApc?= =?us-ascii?q?LhR6ROIFBOYFScBU7gkOCSY4Gb4EVjWIBgRkBAQ?= X-IPAS-Result: =?us-ascii?q?A2G/AADYDyBb/yYyC4dcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?wU4FPEigKg26IBIxpgX+UW4F4CyyEQAIXghwhNBgBAgEBAQEBAQICAmkohSoBA?= =?us-ascii?q?QEBAgESERFDBwcEAgEIDQQEAQEBAgIGHQMCAgIwFAEICAIEARIIEQmEeQgBoU6?= =?us-ascii?q?JbIIcGgKILYFogQuHPYFVPoQbhF0YFYJqMYIkAodSkTQJApcLhR6ROIFBOYFSc?= =?us-ascii?q?BU7gkOCSY4Gb4EVjWIBgRkBAQ?= X-IronPort-AV: E=Sophos;i="5.51,215,1526356800"; d="scan'208";a="244266233" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jun 2018 14:27:11 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 14:27:11 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0382.000; Tue, 12 Jun 2018 14:27:10 -0400 From: "Mudric, Dusan (Dusan)" To: Richard Patterson , "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt Thread-Index: AQHUAmYQQ+0soWtnZE2MJIS2QBWzJqRc5NHQ Date: Tue, 12 Jun 2018 18:27:10 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB08439@AZ-US1EXMB03.global.avaya.com> References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:27:20 -0000 SGkgUmljaGFyZCwNCg0KRXZlbiBpZiB0aGUgaW50ZW50aW9uIGlzIG5vdCB0byBjaGFuZ2UgdGhl IGV4aXN0aW5nIERIQ1B2NiBwcm90b2NvbCAib24gdGhlIHdpcmUiLCBJIHRoaW5rIHlvdSBuZWVk IHRvIGNsYXJpZnkgYSBiaXQgdGhlIHNlY3Rpb24gIiA0LjMuICBCZWhhdmlvdXIgMjogRXhwaXJl IExlYXNlIi4gRm9yIGV4YW1wbGUsIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGV4aXN0aW5nIGxl YXNlIGV2ZW4gd2l0aCB0aGUgbmV3IHNvbGljaXRhdGlvbi4gDQoNCkZvciBjbGllbnQgdG8ga2Vl cCB0aGUgZXhpc3RpbmcgbGVhc2UsIHRoZSBESENQdjYgc2VydmVyIGFuZCBsZWFzZSBzZWxlY3Rp b24gYWxnb3JpdGhtIG5lZWRzIHRvIGNoYW5nZSBhZnRlciBBRFZFUlRJU0UuIElmIHRoZSBzZXJ2 ZXIgcHJlZmVyZW5jZSBoYXMgY2hhbmdlZCwgdGhlIGNsaWVudCBzaG91bGQgbm90IHNlbGVjdCB0 aGUgc2VydmVyIHdpdGggdGhlIGhpZ2hlc3QgT1BUSU9OX1BSRUZFUkVOQ0UsIGJ1dCByYXRoZXIg dGhlIG9uZSB0aGF0IGlzc3VlZCB0aGUgY3VycmVudCBsZWFzZS4gQ29uc2lkZXJpbmcgdGhlIGxl YXNlIHdpbGwgbm90IGJlIFJFTEVBU0UtZCwgdGhlIHNlcnZlciB3aWxsIG5vdCBvZmZlciB0aGUg bGVhc2UgZm9yIHRoZSBuZXcgc29saWNpdGF0aW9uLiBUaGUgY2xpZW50IHNob3VsZCB1c2UgU2Vy dmVyIElkZW50aWZpZXIgdG8gc2VsZWN0IHRoZSBwcmVmZXJyZWQgc2VydmVyLg0KDQpJZiB0aGUg c2VydmVyIHRoYXQgaXNzdWVkIHRoZSBsZWFzZSBpcyBub3QgdGhlIG1vc3QgcHJlZmVycmVkIGFu eSBtb3JlLCB0aGUgY2xpZW50IHNob3VsZCBpZ25vcmUgdGhlIE9QVElPTl9VTklDQVNUIGZyb20g dGhlIG1vc3QgcHJlZmVycmVkIHNlcnZlciwgYW5kIHNob3VsZCB1bmljYXN0IFJFUUVTVCwgd2l0 aCB0aGUgZXhpc3RpbmcgbGVhc2UsIHRvIHRoZSBzZXJ2ZXIgdGhhdCBpc3N1ZWQgdGhlIGxlYXNl LCBvciBtdWx0aWNhc3QgUkVRVUVTVC4NCg0KUmVnYXJkcywNCkR1c2FuLg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJpY2hhcmQgUGF0dGVyc29uIFttYWlsdG86cmlj aGFyZEBoZWxpeC5uZXQubnpdDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTggMTE6NTcg QU0NCj4gVG86IHY2b3BzQGlldGYub3JnIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgTXVkcmljLCBE dXNhbiAoRHVzYW4pDQo+IDxkbXVkcmljQGF2YXlhLmNvbT4NCj4gU3ViamVjdDogUmU6IFt2Nm9w c10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wYXR0ZXJzb24taW50YXJlYS0N Cj4gaXBvZS1oZWFsdGgtMDEudHh0DQo+IA0KPiBIaSBEdXNhbiwNCj4gDQo+IFRoYW5rcyBmb3Ig dGhlIHJldmlldywgcmVzcG9uc2VzIGluLWxpbmU6DQo+IA0KPiBPbiBUdWUsIDEyIEp1biAyMDE4 IGF0IDE2OjA3LCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29tPg0KPiB3 cm90ZToNCj4gPg0KPiA+IEhpIFJpY2hhcmQsDQo+ID4NCj4gPiAiNC4zLiAgQmVoYXZpb3VyIDI6 IEV4cGlyZSBMZWFzZSINCj4gPg0KPiA+IFR5cG86IEJlaGF2aW9yDQo+IFtSUF0gSXNuJ3QgQnJp dGlzaCBzcGVsbGluZyBhY2NlcHRlZCBhcyBsb25nIGFzIGl0J3MgY29uc2lzdGVudA0KPiB0aHJv dWdob3V0IHRoZSBkb2N1bWVudD8gIEkgY2FuIHMvYmVoYXZpb3VyL2JlaGF2aW9yLyBpZiByZXF1 aXJlZC4NCj4gDQo+ID4gLSBJcyB0aGlzIG9wdGlvbiBhbiBhdHRlbXB0IGZvciB0aGUgbGVhc2Ug UkVORVctYWwgYnV0IG5vdCB1c2luZyBSRU5FVz8NCj4gW1JQXSBUaGlzIGFjdGlvbiBpcyBmb3Ig d2hlbiB0aGUgc3Vic2NyaWJlciBzdGF0ZSBpbiB0aGUgbmV0d29yayBoYXMNCj4gYmVlbiBsb3N0 LCByZWd1bGFyIFJFTkVXcyB3aWxsIGxpa2VseSBiZSBkcm9wcGVkIGJ5IHRoZSBuZXR3b3JrLCB1 bnRpbA0KPiB0aGUgbmV0d29yayBjYW4gYXV0aGVudGljYXRlIHRoZSBJUG9FIENsaWVudCBhZ2Fp biwgd2hpY2ggaXMgdXN1YWxseQ0KPiBkb25lIGJhc2VkIG9uIGEgREhDUHY0IERJU0NPVkVSIG9y IERIQ1B2NiBTT0xJQ0lULg0KPiANCj4gPiAtIElmIG5vdCwgd2hhdCBpcyB0aGUgYmVuZWZpdCBv ZiBub3Qgc2VuZGluZyBSRUxFQVNFPw0KPiBbUlBdICBBIFJlbGVhc2UgaW5zdHJ1Y3RzIHRoZSBE SENQIHNlcnZlciB0byByZWxpbnF1aXNoIHRoZSBsZWFzZQ0KPiBlbnRpcmVseS4gIEF2b2lkaW5n IHRoaXMgc3RlcCBhbGxvd3MgYSBjbGllbnQgdG8gcG90ZW50aWFsbHkgcmViaW5kDQo+IHRoZSBw cmV2aW91c2x5IGxlYXNlZCBJUC9wcmVmaXgsIHdoaWNoIGNhbiByZWR1Y2UgdGhlIGN1c3RvbWVy DQo+IGV4cGVyaWVuY2UgaW1wYWN0IHdoZW4gb3BlcmF0aW5nIHdpdGggZHluYW1pYyBsZWFzZXMu DQo+IA0KPiA+IC0gSWYgeWVzLCBpcyBESENQdjYgY2xpZW50IGdvaW5nIHRvIHNlbmQgdGhlIHNh bWUgYWRkcmVzcyBpbiBTT0xJQ0lUPyBJcw0KPiBESENQdjYgY2xpZW50IGdvaW5nIHRvIHVuaWNh c3QgU09MSUNJVCB0byB0aGUgc2FtZSBESENQdjYgc2VydmVyLCBpZg0KPiBPUFRJT05fVU5JQ0FT VCB3YXMgc2V0IGZvciB0aGUgbGVhc2U/DQo+IFtSUF0gVGhpcyBkb2N1bWVudCByZWxpZXMgb24g ZXhpc3RpbmcgREhDUCBtZXNzYWdpbmcsIGFuZCB3ZSBkb24ndA0KPiB3YW50IHRvIGFkanVzdCB0 aGF0IGJlaGF2aW91ci4gIEkgZG9uJ3QgYmVsaWV2ZSBhbnl0aGluZyBpbiAzMzE1DQo+IHNwZWNp ZmllcyB0aGF0IGEgU09MSUNJVCBjb3VsZCBiZSB1bmljYXN0IGZvbGxvd2luZyBhIGxlYXNlDQo+ IGV4cGlyYXRpb24/ICBJIGJlbGlldmUgT1BUSU9OX1VOSUNBU1QgaXMgZm9yIGp1c3QgaW4tbGlm ZSBtZXNzYWdpbmcgYXMNCj4gb3Bwb3NlZCB0byBzZXJ2ZXIgZGlzY292ZXJ5LCBidXQgSSBjb3Vs ZCBiZSB3cm9uZy4NCj4gVGhlIGNsaWVudCBjYW4gaW5jbHVkZSB0aGUgcHJldmlvdXNseSBsZWFz ZWQgcHJlZml4IGluIHRoZSBSRVFVRVNULA0KPiB0aGUgc2VydmVyIG1heSBhY2NlcHQgaXQgaWYg aXQncyBhdmFpbGFibGUsIG9yIE5BSyBpdC4NCj4gDQo+IFRvIHNpbXBsaWZ5IGFkb3B0aW9uIHdl J3ZlIGF0dGVtcHRlZCB0byByZXVzZSBleGlzdGluZyBmdW5jdGlvbmFsaXR5DQo+IHdoZXJlIHBv c3NpYmxlLCBoZW5jZSB0aGUgdXNlIG9yIEFSUC9ORCBhbmQganVzdCBhZGp1c3RpbmcgdGhlIFQx L1QyDQo+IHRpbWVycyB0byB0cmlnZ2VyIHRoZSB1c3VhbCBESENQIHByb2Nlc3Nlcy4NCj4gDQo+ IEdpdmVuIHRoZSBhYm92ZSwgRHVzYW4sIGRvIHlvdSB0aGluayB0aGUgd29yZGluZyBpbiB0aGUg ZHJhZnQgbmVlZHMNCj4gY2xhcmlmaWNhdGlvbj8NCj4gDQo+IC1SaWNoYXJkDQo= From nobody Tue Jun 12 13:54: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 3AF36130DE3 for ; Tue, 12 Jun 2018 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvCiXSptIX9S for ; Tue, 12 Jun 2018 13:54:23 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2201271FF for ; Tue, 12 Jun 2018 13:54:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id D0BBFFABCF0 for ; Tue, 12 Jun 2018 17:54:19 -0300 (ART) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fe07lwvKcp-9 for ; Tue, 12 Jun 2018 17:54:18 -0300 (ART) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id BB6B0FAC81C for ; Tue, 12 Jun 2018 17:54:18 -0300 (ART) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar BB6B0FAC81C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=AF3BF44E-65A6-11E7-AE62-64B2068F9D73; t=1528836858; bh=Ym9JrDAB9EGHYDBs7zgAOPiwnOJVJU5QqNfrRS4tmiQ=; h=Date:From:To:Message-ID:MIME-Version; b=pOMsqrUHk3BkYURbiZpXJu9ukHuoVQ+b68R7cRm0pvGkCrWUwdONyVrVLiYkPNqjd u43FJPm/o6sdrtehud6We+OOLO6wV2t4L6xTHwrn65mAJC+btWGyxbmCQ4VoTrpbfM v1446cq/mcilxbgpKE0CJ9cAcn2O4qdVkhrATVzq7uVyBD6+JEW/YAG4M6cWlHObt3 hdYHgkiztA5gSC4bBbFmBP7J/VnDG0jFOInni+XgVXFLr56rgduD3L9U3NGaow41y4 wP4uid1exW90LOHRCeDc5dRgD/IbT/2PUMtWKu+s8R1WqV26VrobRekbAW3FDK/aGb yL7r5gqkmLsjg== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ggvd93kBd6F3 for ; Tue, 12 Jun 2018 17:54:18 -0300 (ART) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 9D17AFABCF0 for ; Tue, 12 Jun 2018 17:54:18 -0300 (ART) Date: Tue, 12 Jun 2018 17:54:18 -0300 (ART) From: Alejandro D'Egidio To: v6ops@ietf.org Message-ID: <447447433.60787468.1528836858573.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: <1E283759-AB5E-4D0A-A6E6-2A06B95E7D6C@consulintel.es> <980A4003-336C-4B99-BFD2-725B261F40BA@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - GC67 (Win)/8.7.0_GA_1659) Thread-Topic: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Thread-Index: 3A9bMgDRW4IZaEXTzSmSkapPyW+AAw== Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 20:54:29 -0000 Hello, First at all, I've read all the thread and I think this is a very useful di= scussion. I work in a cable operator and I think 464XLAT is a great idea to be includ= ed in CPEs. So, everything related to that is interesting for me. I have some questions: 1- Why the RFC8026 can include Option Codes for many transition methods and= not for 464XLAT? 2- Why we can't have an alternative to RFC7050 and RFC7225? 3- What if some CPEs works fine with some RFCs and not with other? Shouldn'= t be better to have alternatives? It's really common to have many Bugs in C= PEs specially with new protocols. They can say they support some RFC but it= doesn't work and you will need to wait some months (if you're lucky) to ge= t the solution. 4- In our cablemodems we doesn't allow to customer to modify DNS configurat= ion but, what about if customer change cablemodem to Bridge Mode and connec= ts it's own CPE? This is a usual case where you can't control DNS configura= tion but you still want to use 464XLAT. Thanks and Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025=C2=A0 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Philip Homburg" , v6ops@ietf.org Enviados: Martes, 12 de Junio 2018 7:48:07 Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas I think my earlier email to Lorenzo provides answers to most of this ... bu= t > I see your point, but > what an operator need is a "100% sure" way to make sure that they > can tell the CPE to not use a specific transition mechanism (which > for the other mechanisms we have with RFC8026). >=20 > So, assuming that DNS64 is only there if combined with NAT64 is > not "safe 100%" because if using CLAT, you can avoid having a DNS64 > (this is the one that breaks DNSSEC, in case I wrote it incorrectly > before). =20 I'm saying that if an operator uses DNS64 to signal the presence of NAT= 64, then that is a reliable signal that doesn't need an additional DHCP opt= ion. =20 So if is safe for a CPE to just do RFC7050, because if DNS64 is detecte= d, you can be sure that the operator wants the CPE to use NAT64. As said, you can use the CLAT w/o DNS64, so it is not a safe way to detect = the CPE should use or not the NAT64. =20 > But if the user changed the DNS in the CPE (which is quite common), > there will not be DNS64 and still may be the ISP want to have the > CLAT running, because is using that for the IPv4 service for that > particular customer. =20 Yeah, what if the user changes settings? Maybe the CPE has a way to for= ce=20 NAT64 on. What do you do then? All bets are off when users start changi= ng settings. An operator wants to make it as proof as possible to user changes. A user h= as no interest in changing the status of NAT64 (probably they don't know wh= at it means), but they have interested in changing the DNS, because many ap= ps or web sites tell them to change it. =20 In the context of RFC7050, the CPE can opt to use the original resolver= s provided by upstream to figure out the translation prefix. =20 Note that if the CPE uses resolvers configured by the user for RFC7050,= then is it quite possible that the translation prefix is not discovered (for= example if the user configures a well known public resolver). Or worse,=20 the user may configure a DNS64 resolver that uses a different prefix. Right, that's one case, using an alternative DNS64, which will bring altern= ative NAT64, unless/or the operator is using PCP for the NAT64 provisioning= . =20 > If you agree that the CPE may request a PCP option, etc., then > request the S46, I think you are in agreement that we need the S46 > priority option codes for all the mechanism that we are asking to > be supported by the CPE, right? =20 To the extent that RFC8026 is incomplete, that should be fixed. However= as Section 2.2 describes, what S46 offers can be done already be done by t= he DHCPv6 server. So S46 just provides a relative priority of different mechanisms, not an on/off switch for NAT64. =20 What it makes this work is the combination of RFC8026 and the CPE behavior.= The idea is to have a S46 option to provide a priority in a list of "possi= ble" transition mechanism to a given CPE. If the operator doesn't want that= a specific CPE uses NAT64, then the S46 will not contain that option, so t= he CE will not use it, because will not have a match (even if the CPE is ab= le to use 464XLAT). Not sure if this explanation clarify it ? I'm working o= n the precise text for that in the ID ... =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jun 12 18:29: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 28E65130DC6; Tue, 12 Jun 2018 18:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 L2584IejuVLj; Tue, 12 Jun 2018 18:29:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0ED812777C; Tue, 12 Jun 2018 18:29:37 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C898B3AB007; Wed, 13 Jun 2018 01:29:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A86FB160050; Wed, 13 Jun 2018 01:29:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 818D616006C; Wed, 13 Jun 2018 01:29:35 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TBMGjsgf0sYl; Wed, 13 Jun 2018 01:29:35 +0000 (UTC) Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 46A73160050; Wed, 13 Jun 2018 01:29:34 +0000 (UTC) From: Mark Andrews Content-Type: multipart/alternative; boundary="Apple-Mail=_5F9CB04F-A666-452E-85E9-4B0B867A3F0F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Jun 2018 11:29:31 +1000 References: Cc: Michelle Cotton via RT To: dnsop , "v6ops@ietf.org WG" Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 01:29:42 -0000 --Apple-Mail=_5F9CB04F-A666-452E-85E9-4B0B867A3F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The Domain Name Reservation Considerations in RFC 7050 do not cover = whether a delegation should be signed or not. Due to that omission in = constructing the set of questions to be asked RFC 7050 fails when the client is behind a = validating resolver that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. There are 2 pieces of work that are required. 1) update the list of questions that need to be asked needs to include = whether a delegation needs to be signed or not. 2) update RFC 7050 to include explicit instructions to say DO NOT sign = IPV4ONLY.ARPA. Item 1 is dnsop work as far as I can see. Item 2, I think, should be = v6ops work. HOME.ARPA is a example of a unsigned delegation. 10.IN-ADDR.ARPA is a example of a unsigned delegation. There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on = the Internet are well known. The contents with NAT64 in using are well known except = for the AAAA query. The answer to that query is *expected to change*. That = answer cannot be validated. Mark > Begin forwarded message: >=20 > From: "Michelle Cotton via RT" > Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure. > Date: 6 January 2018 at 8:45:10 am AEDT > To: marka@isc.org > Reply-To: iana-questions@iana.org >=20 > Hello, >=20 > Following up on a thread from the end of the year. Who will bring = this to the DNSOps working group? Will someone notify us if there is an = consensus on a conclusion of what needs to be done? >=20 > Thanks in advance. >=20 > --Michelle Cotton >=20 >=20 > On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote: >> I had replied to the errata. I agree it warrants additional >> discussion, and had also suggested same. Dnsops seems appropriate. >>=20 >>=20 >>=20 >> The question is not to much where the attacker is, but what DNSSEC >> guarantee is provided. DNS64 imagines the client could do its own >> validation =E2=80=94 if it wanted. To date, effectively zero clients = seem to >> want to do their own DNSSEC validation. >>=20 >> -d >>=20 >>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere) >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an >>> email address I found from an I-D.. >>>=20 >>> I'm not really following IETF nowadays, so I don't know if this has >>> been discussed. >>>=20 >>> Also I'm not sure why ISPs couldn=E2=80=99t first verify the A = response's >>> validity and then generate AAAA response to the client as = document... >>> but I suppose it could be considered to be more proper action to >>> modify insecure responses than secure responses. I'm just worried >>> what happens if there's attacker between ISP and root, in which case >>> the IPv4 address part of the response could be modified by attacker >>> and then delivered to client in the ISP's synthetic AAAA record.. >>>=20 >>> So I cannot accept the errata straight away, but it should be >>> discussed with people who are more experts on this than I am. >>>=20 >>> Best regards, >>>=20 >>> Teemu >>>=20 >>>=20 >>> -----Original Message----- >>> From: Michelle Cotton via RT [mailto:iana-questions- >>> comment@iana.org] >>> Sent: 9. joulukuuta 2017 1:22 >>> Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com; >>> jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere) >>> >>> Subject: [IANA #989438] ipv4only.arpa's delegation should be >>> insecure. >>>=20 >>> Hello, >>>=20 >>> Just checking to see if anyone had a chance to look at this. >>> Dan Wing's email addressed bounced (dwing@cisco.com). >>>=20 >>> Thanks, >>> Michelle >>>=20 >>>=20 >>>=20 >>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: >>>> Hello Authors and Area Directors, >>>>=20 >>>> We have received a message pointing out an errata report that would >>>> modify the actions that were performed for RFC7050. >>>>=20 >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc- >>>> = 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DIMDU= 0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCK= CSggUUCCU7iPuRs- >>>> usGcL3T69Fia9gTOy4UQwhLk&e=3D >>>>=20 >>>> Has this report been discussed? Will the result be an approved >>>> errata >>>> report or a new RFC? >>>>=20 >>>> Thanks in advance. >>>>=20 >>>> Michelle Cotton >>>> Protocol Parameters Engagement Sr. Manager >>>=20 >>>=20 >>>=20 >=20 >=20 >=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --Apple-Mail=_5F9CB04F-A666-452E-85E9-4B0B867A3F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The Domain = Name Reservation Considerations in RFC 7050 do not cover whether
a = delegation should be signed or not.  Due to that omission in = constructing the set
of questions to be = asked RFC 7050 fails when the client is behind a validating = resolver
that has NO SPECIAL KNOWLEDGE of = IPV4ONLY.ARPA.

There are 2 pieces of work that are required.
1) update the list of questions that need to be asked needs = to include whether a delegation
    needs = to be signed or not.
2) update RFC 7050 to = include explicit instructions to say DO NOT sign = IPV4ONLY.ARPA.

Item 1 is dnsop work as far as I can see.  Item 2, I = think, should be v6ops work.

HOME.ARPA is a example of a unsigned = delegation.
10.IN-ADDR.ARPA is a example of a = unsigned delegation.

There is zero benefit in IPV4ONLY.ARPA being signed. =  Its contents on the Internet
are well known. =  The contents with NAT64 in using are well known except for = the
AAAA query.  The answer to that query is = *expected to change*.  That answer cannot
be = validated.

Mark

Begin forwarded = message:

From: = "Michelle Cotton via RT" <iana-questions@iana.org>
Subject: = [IANA #989438] = ipv4only.arpa's delegation should be insecure.
Date: = 6 January 2018 at 8:45:10 am = AEDT
To: = marka@isc.org
Reply-To: = iana-questions@iana.org

Hello,

Following up on a thread from the end of the year.  Who = will bring this to the DNSOps working group?  Will someone notify = us if there is an consensus on a conclusion of what needs to be done?

Thanks in advance.

--Michelle Cotton


On Sun Dec 10 22:40:29 2017, danwing@gmail.com = wrote:
I had replied = to the errata. I agree it warrants additional
discussion, = and had also suggested same. Dnsops seems appropriate.



The question is not to much = where the attacker is, but what DNSSEC
guarantee is = provided. DNS64 imagines the client could do its own
validation =E2=80=94 if it wanted.  To date, effectively = zero clients seem to
want to do their own DNSSEC = validation.

-d

On Dec 10, 2017, at = 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere)
<teemu.savolainen@nokia.com> wrote:

Hi,

Dan Wing seem to have moved = to VMWare, but cc'ing him now with an
email address I = found from an I-D..

I'm not really = following IETF nowadays, so I don't know if this has
been = discussed.

Also I'm not sure why ISPs = couldn=E2=80=99t first verify the A response's
validity = and then generate AAAA response to the client as document...
but I suppose it could be considered to be more proper action = to
modify insecure responses than secure responses. I'm = just worried
what happens if there's attacker between ISP = and root, in which case
the IPv4 address part of the = response could be modified by attacker
and then delivered = to client in the ISP's synthetic AAAA record..

So I cannot accept the errata straight away, but it should = be
discussed with people who are more experts on this than = I am.

Best regards,

Teemu


-----Original= Message-----
From: Michelle Cotton via RT = [mailto:iana-questions-
comment@iana.org]
Sent: 9. joulukuuta 2017 = 1:22
Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com;
jouni.nospam@gmail.com; Savolainen, Teemu = (Nokia-TECH/Tampere)
<teemu.savolainen@nokia.com>
Subject: = [IANA #989438] ipv4only.arpa's delegation should be
insecure.

Hello,
Just checking to see if anyone had a chance to look at = this.
Dan Wing's email addressed bounced (dwing@cisco.com).

Thanks,
Michelle


On Tue Nov 28 14:43:00 2017, michelle.cotton wrote:
Hello Authors and Area Directors,

We have received a message pointing out an errata report that = would
modify the actions that were performed for = RFC7050.

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc-=
2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOV= oH58JNXRgQ&r=3DIMDU0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h= 76vuapCYz_DxRRq7SkM&s=3DuCKCSggUUCCU7iPuRs-
usGcL3T69Fia9gTOy4UQwhLk&e=3D

Has this report been discussed?  Will the result be an = approved
errata
report or a new RFC?

Thanks in advance.

Michelle Cotton
Protocol Parameters Engagement = Sr. Manager







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

= --Apple-Mail=_5F9CB04F-A666-452E-85E9-4B0B867A3F0F-- From nobody Tue Jun 12 19:28: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 BAD99126F72 for ; Tue, 12 Jun 2018 19:28:27 -0700 (PDT) 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_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rVPwLhVsmyz for ; Tue, 12 Jun 2018 19:28:20 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAA2127332 for ; Tue, 12 Jun 2018 19:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528856899; x=2392770499; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/JXwA2INf/LZHv40ZC0ems4b3dCbyRsW+NTkXU1jMBQ=; b=ff7yYaQyxjkjc9ygOwWdr5kU5Pf91XHtzIyd10KKB5ba/7wxaa5hRJjOgBeWPW9q SJdtrgw8UdkBbn08Hacgzua87d/lp3ku6mu8J63d/j3w8Zv7Crn3sRzC3p3RvMH4 8RE6YC6jly+nSTOM9Glg9TG/JcIRCB3ovO1q4CeGnQfjLsqDQ3tcZvSO+LYYtXIS uxX/Eo3OX9MoHD73G/SmHpymb1wuK71grNrmG+iJgK+jiTbPu5n9NZJjf1OCPvX/ OB+mxBVWWsagGQtmhyz02ln5THU5NlfarbjyHO8cavcrYk9UFUppfCDkRorPmY8P eRVtppG0nezNSVyZdVt6Uw==; X-AuditID: 11ab0217-24b109e000003e90-28-5b2081426d8e Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 1E.96.16016.241802B5; Tue, 12 Jun 2018 19:28:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qTOtcWP5HQnSzhlu9/Y4Rw)" Received: from apple.com (nwk-grpmailp-qapp15.corp.apple.com [17.146.97.143]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA8007EJPJ58UB0@mr2-mtap-s01.rno.apple.com>; Tue, 12 Jun 2018 19:28:17 -0700 (PDT) Received: from nwk-grpmailp-qapp15.corp.apple.com (nwk-grpmailp-qapp15.corp.apple.com [127.0.0.1]) by pps.post-v (8.16.0.20/8.16.0.20) with SMTP id w5D2SHwc028569; Tue, 12 Jun 2018 19:28:17 -0700 Received: from [17.234.6.103] ([17.234.6.103]) by nwk-mmpp-sz11.apple.com with ESMTP id 0PA800LYBPI4OR70; Tue, 12 Jun 2018 19:28:17 -0700 Received: from [17.234.6.103] by nwk-mmpp-sz11.apple.com with ESMTPSA; Tue, 12 Jun 2018 19:28:17 -0700 (PDT) From: David Schinazi Message-id: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> Date: Tue, 12 Jun 2018 19:28:16 -0700 In-reply-to: Cc: dnsop , "v6ops@ietf.org WG" , Michelle Cotton via RT , Stuart Cheshire To: Mark Andrews References: X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-12_14:,, signatures=0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUiuPlRq65zo0K0wfoTnBZ331xmsWhdvZTd 4sqL+ywWp4/tZXZg8eiR91iy5CeTx4PH75gDmKO4bFJSczLLUov07RK4Mva3T2IveN7BWPF9 2UL2BsbTZV2MnBwSAiYSrU3bWbsYuTiEBA4yScz99ZEVJMErICjxY/I9FhCbWSBMYunMJ8wQ RauZJM7vusUOkhASOMkoMX2tNkSim1Hi3bepbBCJPIl511uZuhg5ONgEtCQOrDGCGGoj8eHs L7ChwgIhEs9u9jOC2CwCqhJXHywEa+UUsJZYvX4BE8hMZoE5jBIzb/4AS4gIKEi0vX3FBDG/ QGLv3C42iBeUJKZ/vw1lZ0tMXLyUZQKj0CwkT8xC8sQsoJOYBdQlpkzJhQhrSzx5d4EVwlaT WPh7EROy+AJGtlWMwrmJmTm6mXlGxnqJBQU5qXrJ+bmbGEGRsppJfAfj59eGhxgFOBiVeHgf XJSPFmJNLCuuzD3EKM3BoiTO+2GXWLSQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtjTwXLJ F191Rqo/3OcRu3HBw5fFa/bbPN5aoGFwKzKns1Die3Remy3PxhaWgqjebg5HqyX3OS0fnvin c5qNmWv+N+eeRfN3z6567lJj7Tk7S3SVYN6MP/3BFZJlB7KeXXvgIukVMXmhUq2dhURVdkrJ puv9Dd5XDUX1DxvMtlJs2JVR/vCIEktxRqKhFnNRcSIAVqdN0XUCAAA= Archived-At: Subject: Re: [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 02:28:28 -0000 --Boundary_(ID_qTOtcWP5HQnSzhlu9/Y4Rw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi everyone, Stuart and I have a draft that attempts to address these issues, please = let us know if you think it does or doesn't. https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa = Thanks, David Schinazi > On Jun 12, 2018, at 18:29, Mark Andrews wrote: >=20 > The Domain Name Reservation Considerations in RFC 7050 do not cover = whether > a delegation should be signed or not. Due to that omission in = constructing the set > of questions to be asked RFC 7050 fails when the client is behind a = validating resolver > that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. >=20 > There are 2 pieces of work that are required. > 1) update the list of questions that need to be asked needs to include = whether a delegation > needs to be signed or not. > 2) update RFC 7050 to include explicit instructions to say DO NOT sign = IPV4ONLY.ARPA. >=20 > Item 1 is dnsop work as far as I can see. Item 2, I think, should be = v6ops work. >=20 > HOME.ARPA is a example of a unsigned delegation. > 10.IN-ADDR.ARPA is a example of a unsigned delegation. >=20 > There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on = the Internet > are well known. The contents with NAT64 in using are well known = except for the > AAAA query. The answer to that query is *expected to change*. That = answer cannot > be validated. >=20 > Mark >=20 >> Begin forwarded message: >>=20 >> From: "Michelle Cotton via RT" > >> Subject: [IANA #989438] ipv4only.arpa's delegation should be = insecure. >> Date: 6 January 2018 at 8:45:10 am AEDT >> To: marka@isc.org >> Reply-To: iana-questions@iana.org >>=20 >> Hello, >>=20 >> Following up on a thread from the end of the year. Who will bring = this to the DNSOps working group? Will someone notify us if there is an = consensus on a conclusion of what needs to be done? >>=20 >> Thanks in advance. >>=20 >> --Michelle Cotton >>=20 >>=20 >> On Sun Dec 10 22:40:29 2017, danwing@gmail.com = wrote: >>> I had replied to the errata. I agree it warrants additional >>> discussion, and had also suggested same. Dnsops seems appropriate. >>>=20 >>>=20 >>>=20 >>> The question is not to much where the attacker is, but what DNSSEC >>> guarantee is provided. DNS64 imagines the client could do its own >>> validation =E2=80=94 if it wanted. To date, effectively zero = clients seem to >>> want to do their own DNSSEC validation. >>>=20 >>> -d >>>=20 >>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu = (Nokia-TECH/Tampere) >>>> > = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an >>>> email address I found from an I-D.. >>>>=20 >>>> I'm not really following IETF nowadays, so I don't know if this has >>>> been discussed. >>>>=20 >>>> Also I'm not sure why ISPs couldn=E2=80=99t first verify the A = response's >>>> validity and then generate AAAA response to the client as = document... >>>> but I suppose it could be considered to be more proper action to >>>> modify insecure responses than secure responses. I'm just worried >>>> what happens if there's attacker between ISP and root, in which = case >>>> the IPv4 address part of the response could be modified by attacker >>>> and then delivered to client in the ISP's synthetic AAAA record.. >>>>=20 >>>> So I cannot accept the errata straight away, but it should be >>>> discussed with people who are more experts on this than I am. >>>>=20 >>>> Best regards, >>>>=20 >>>> Teemu >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Michelle Cotton via RT [mailto:iana-questions- >>>> comment@iana.org ] >>>> Sent: 9. joulukuuta 2017 1:22 >>>> Cc: ietf@kuehlewind.net ; = spencerdawkins.ietf@gmail.com ; >>>> jouni.nospam@gmail.com ; Savolainen, = Teemu (Nokia-TECH/Tampere) >>>> > >>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be >>>> insecure. >>>>=20 >>>> Hello, >>>>=20 >>>> Just checking to see if anyone had a chance to look at this. >>>> Dan Wing's email addressed bounced (dwing@cisco.com = ). >>>>=20 >>>> Thanks, >>>> Michelle >>>>=20 >>>>=20 >>>>=20 >>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: >>>>> Hello Authors and Area Directors, >>>>>=20 >>>>> We have received a message pointing out an errata report that = would >>>>> modify the actions that were performed for RFC7050. >>>>>=20 >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc- = >>>>> = 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DIMDU= 0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCK= CSggUUCCU7iPuRs- >>>>> usGcL3T69Fia9gTOy4UQwhLk&e=3D >>>>>=20 >>>>> Has this report been discussed? Will the result be an approved >>>>> errata >>>>> report or a new RFC? >>>>>=20 >>>>> Thanks in advance. >>>>>=20 >>>>> Michelle Cotton >>>>> Protocol Parameters Engagement Sr. Manager >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org = > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_qTOtcWP5HQnSzhlu9/Y4Rw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = everyone,

Stuart and = I have a draft that attempts to address these issues, please let us know = if you think it does or doesn't.

https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-ar= pa

Thanks,
David Schinazi


On Jun 12, 2018, at 18:29, Mark Andrews = <marka@isc.org> = wrote:

The Domain Name Reservation = Considerations in RFC = 7050 do not cover whether
a delegation should be = signed or not.  Due to that omission in constructing the = set
of questions to be asked RFC 7050 fails = when the client is behind a validating resolver
that = has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA.

There are 2 pieces of work that are = required.
1) update the list of questions that need = to be asked needs to include whether a delegation
    needs to be signed or not.
2) update RFC 7050 to include explicit instructions to = say DO NOT sign IPV4ONLY.ARPA.

Item 1 is dnsop work as far as I can = see.  Item 2, I think, should be v6ops work.
HOME.ARPA is a example of a unsigned = delegation.
10.IN-ADDR.ARPA is a example of a = unsigned delegation.

There is zero benefit in IPV4ONLY.ARPA being signed. =  Its contents on the Internet
are well known. =  The contents with NAT64 in using are well known except for = the
AAAA query.  The answer to that query is = *expected to change*.  That answer cannot
be = validated.

Mark

Begin = forwarded message:

From: "Michelle Cotton via RT" <iana-questions@iana.org>
Subject: [IANA #989438] ipv4only.arpa's delegation should be = insecure.
Date: 6 January 2018 at 8:45:10 am AEDT
To: marka@isc.org
Reply-To: iana-questions@iana.org

Hello,

Following up on a thread from the end of the year.  Who = will bring this to the DNSOps working group?  Will someone notify = us if there is an consensus on a conclusion of what needs to be done?

Thanks in advance.

--Michelle Cotton


On Sun Dec 10 22:40:29 2017, danwing@gmail.com = wrote:
I had replied = to the errata. I agree it warrants additional
discussion, = and had also suggested same. Dnsops seems appropriate.



The question is not to much = where the attacker is, but what DNSSEC
guarantee is = provided. DNS64 imagines the client could do its own
validation =E2=80=94 if it wanted.  To date, effectively = zero clients seem to
want to do their own DNSSEC = validation.

-d

On Dec 10, 2017, at = 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere)
<teemu.savolainen@nokia.com> wrote:

Hi,

Dan Wing seem to have moved = to VMWare, but cc'ing him now with an
email address I = found from an I-D..

I'm not really = following IETF nowadays, so I don't know if this has
been = discussed.

Also I'm not sure why ISPs = couldn=E2=80=99t first verify the A response's
validity = and then generate AAAA response to the client as document...
but I suppose it could be considered to be more proper action = to
modify insecure responses than secure responses. I'm = just worried
what happens if there's attacker between ISP = and root, in which case
the IPv4 address part of the = response could be modified by attacker
and then delivered = to client in the ISP's synthetic AAAA record..

So I cannot accept the errata straight away, but it should = be
discussed with people who are more experts on this than = I am.

Best regards,

Teemu


-----Original= Message-----
From: Michelle Cotton via RT = [mailto:iana-questions-
comment@iana.org]
Sent: 9. joulukuuta 2017 = 1:22
Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com;
jouni.nospam@gmail.com; Savolainen, Teemu = (Nokia-TECH/Tampere)
<teemu.savolainen@nokia.com>
Subject: = [IANA #989438] ipv4only.arpa's delegation should be
insecure.

Hello,
Just checking to see if anyone had a chance to look at = this.
Dan Wing's email addressed bounced (dwing@cisco.com).

Thanks,
Michelle


On Tue Nov 28 14:43:00 2017, michelle.cotton wrote:
Hello Authors and Area Directors,

We have received a message pointing out an errata report that = would
modify the actions that were performed for = RFC7050.

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc-=
2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOV= oH58JNXRgQ&r=3DIMDU0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h= 76vuapCYz_DxRRq7SkM&s=3DuCKCSggUUCCU7iPuRs-
usGcL3T69Fia9gTOy4UQwhLk&e=3D

Has this report been discussed?  Will the result be an = approved
errata
report or a new RFC?

Thanks in advance.

Michelle Cotton
Protocol Parameters Engagement = Sr. Manager







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

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

= --Boundary_(ID_qTOtcWP5HQnSzhlu9/Y4Rw)-- From nobody Tue Jun 12 19:36: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 5EFED130DC2 for ; Tue, 12 Jun 2018 19:36:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t5B84DCxkr5 for ; Tue, 12 Jun 2018 19:36:15 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F616126F72 for ; Tue, 12 Jun 2018 19:36:15 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l19-v6so1804273ioj.5 for ; Tue, 12 Jun 2018 19:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jzcsE2+EXTnQ6+QICo64zzGesuVCPGXiSIkr6qkZuio=; b=YDYPmAKMJ0Uyq8LKj3MGTPka70Vuf9t+TbBzGc9gsXsnZBCjjXMNjjBE40gMBuJPZi baPnXB6bvb3tjFtUoKKI+m20rTvG7yDlHiQnoBpL0tEhxHXu2gAO9Wh+CdYDehr/CTpK vU0r0Ze4KME5mV+EoqUMFhlKYjNWH75qGvvHPiaf/wxe6JrabjX/h3TyUwoR1MvndLWF Xh1R16LnGK2SPVW0wcYkxqIUkwYOEDfpU4OQ7kyLt9oZnMDNxEdiAlGn3uQuwDebLan7 n6BTvnFdXMrmEalthxT2CvrSgCy5YDjjNCQc8eoNoSH82G7AIhJrLWGFtl7oTbiCew5Y 3mAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=jzcsE2+EXTnQ6+QICo64zzGesuVCPGXiSIkr6qkZuio=; b=hhZUmPF+J9o4vQ4oshc8Viy1n8eF24wRM7YHHfi1pNnvop+CCcepRvBnc5RkxxctBW ZHS7D0xEc2jSBOwWgvDYjEmbhhv/Xe+PHBBuIOQHJgomSzE+vOED3RRQXA+Wpq4GZi4k CHCBZKScWcAdfuEaBVJNJiw70Vvg/JolvG3ufScbehrgt7lH4t58RLFVOKoBXrbgBJFV 4J8r45bumCYh6JyVpqzfrzc7+SLJ/ScmsWs4Xh2yMeEUSyFQzLRUVT41hkdRyAwedqBr Hxw7lSeilbl+FoYJwRR6EdWq5/XxdwHq6Zm/Btv6FQYSf+TcH51YEB9gF2kUbi4+/+Q1 MYiw== X-Gm-Message-State: APt69E3Ln6p5d1Rtv+76Be0w/rXaYODkLprZhTm76AXcqa9GPPhr22DL L1v1TYYZGimiBzeMk4aLM9lO7xHaPOP6EghcgNqw4g== X-Google-Smtp-Source: ADUXVKIpTy+TcH1Wbvmlq7HAKme3HzKSuMh6w9G/4TXLb4ZDvWZrdAXRE8HAmX9fGzXNv8UGz65mrNwxiYV4Lu+uER8= X-Received: by 2002:a6b:9156:: with SMTP id t83-v6mr3154874iod.32.1528857374595; Tue, 12 Jun 2018 19:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6f86:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 19:35:34 -0700 (PDT) In-Reply-To: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> From: Ted Lemon Date: Tue, 12 Jun 2018 19:35:34 -0700 Message-ID: To: David Schinazi Cc: Mark Andrews , Stuart Cheshire , Michelle Cotton via RT , dnsop , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000b9b592056e7cd88c" Archived-At: Subject: Re: [v6ops] [DNSOP] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 02:36:24 -0000 --000000000000b9b592056e7cd88c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM. It sounds like Mark is arguing that RFC6761 also needs updated. Possibly this document could do that, but it would need to be reframed a bit. On Tue, Jun 12, 2018 at 7:28 PM, David Schinazi wrote= : > Hi everyone, > > Stuart and I have a draft that attempts to address these issues, please > let us know if you think it does or doesn't. > > https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa > > Thanks, > David Schinazi > > > On Jun 12, 2018, at 18:29, Mark Andrews wrote: > > The Domain Name Reservation Considerations in RFC 7050 do not cover > whether > a delegation should be signed or not. Due to that omission in > constructing the set > of questions to be asked RFC 7050 fails when the client is behind a > validating resolver > that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. > > There are 2 pieces of work that are required. > 1) update the list of questions that need to be asked needs to include > whether a delegation > needs to be signed or not. > 2) update RFC 7050 to include explicit instructions to say DO NOT sign > IPV4ONLY.ARPA. > > Item 1 is dnsop work as far as I can see. Item 2, I think, should be > v6ops work. > > HOME.ARPA is a example of a unsigned delegation. > 10.IN-ADDR.ARPA is a example of a unsigned delegation. > > There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on the > Internet > are well known. The contents with NAT64 in using are well known except > for the > AAAA query. The answer to that query is *expected to change*. That > answer cannot > be validated. > > Mark > > Begin forwarded message: > > *From: *"Michelle Cotton via RT" > *Subject: **[IANA #989438] ipv4only.arpa's delegation should be insecure.= * > *Date: *6 January 2018 at 8:45:10 am AEDT > *To: *marka@isc.org > *Reply-To: *iana-questions@iana.org > > Hello, > > Following up on a thread from the end of the year. Who will bring this t= o > the DNSOps working group? Will someone notify us if there is an consensu= s > on a conclusion of what needs to be done? > > Thanks in advance. > > --Michelle Cotton > > > On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote: > > I had replied to the errata. I agree it warrants additional > discussion, and had also suggested same. Dnsops seems appropriate. > > > > The question is not to much where the attacker is, but what DNSSEC > guarantee is provided. DNS64 imagines the client could do its own > validation =E2=80=94 if it wanted. To date, effectively zero clients see= m to > want to do their own DNSSEC validation. > > -d > > On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere) > wrote: > > Hi, > > Dan Wing seem to have moved to VMWare, but cc'ing him now with an > email address I found from an I-D.. > > I'm not really following IETF nowadays, so I don't know if this has > been discussed. > > Also I'm not sure why ISPs couldn=E2=80=99t first verify the A response's > validity and then generate AAAA response to the client as document... > but I suppose it could be considered to be more proper action to > modify insecure responses than secure responses. I'm just worried > what happens if there's attacker between ISP and root, in which case > the IPv4 address part of the response could be modified by attacker > and then delivered to client in the ISP's synthetic AAAA record.. > > So I cannot accept the errata straight away, but it should be > discussed with people who are more experts on this than I am. > > Best regards, > > Teemu > > > -----Original Message----- > From: Michelle Cotton via RT [mailto:iana-questions- > comment@iana.org] > Sent: 9. joulukuuta 2017 1:22 > Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com; > jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere) > > Subject: [IANA #989438] ipv4only.arpa's delegation should be > insecure. > > Hello, > > Just checking to see if anyone had a chance to look at this. > Dan Wing's email addressed bounced (dwing@cisco.com). > > Thanks, > Michelle > > > > On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: > Hello Authors and Area Directors, > > We have received a message pointing out an errata report that would > modify the actions that were performed for RFC7050. > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc- > 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3D > IMDU0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s= =3D > uCKCSggUUCCU7iPuRs- > usGcL3T69Fia9gTOy4UQwhLk&e=3D > > Has this report been discussed? Will the result be an approved > errata > report or a new RFC? > > Thanks in advance. > > Michelle Cotton > Protocol Parameters Engagement Sr. Manager > > > > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --000000000000b9b592056e7cd88c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM. =C2=A0 It sounds like Mark is arguing that RFC6761 a= lso needs updated. =C2=A0 Possibly this document could do that, but it woul= d need to be reframed a bit.

On Tue, Jun 12, 2018 at 7:28 PM, David Schinazi <dschi= nazi@apple.com> wrote:
Hi everyone,
Stuart and I have a draft that attempts to address these = issues, please let us know if you think it does or doesn't.
<= br>

Thanks,
David Schinazi


On Jun 12, 2018, at 18:29, Mark Andrews <marka@isc.org> wrote:
The=C2=A0<= span style=3D"font-size:1em">Domain Name Reservation Considerations<= span style=3D"font-size:1em;font-weight:bold"> in RFC 7050 do not cover whether
a delegation should be= signed or not.=C2=A0 Due to that omission in constructing the set
of questions to be asked=C2=A0RFC 7050 fails when the client is behind a = validating resolver
that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARP= A.

There are 2 pieces of work that are required.
1) update the list of questions that need to be asked needs to inc= lude whether a delegation
=C2=A0 =C2=A0 needs to be signed or not= .
2) update=C2=A0RFC 7050 to include explicit instructions to say= DO NOT sign IPV4ONLY.ARPA.

Item 1 is dnsop work a= s far as I can see.=C2=A0 Item 2, I think, should be v6ops work.
=
HOME.ARPA is a example of a unsigned delegation.
1= 0.IN-ADDR.ARPA is a example of a unsigned delegation.

<= div>There is zero benefit in IPV4ONLY.ARPA being signed.=C2=A0 Its contents= on the Internet
are well known.=C2=A0 The contents with NAT64 in= using are well known except for the
AAAA query.=C2=A0 The answer= to that query is *expected to change*.=C2=A0 That answer cannot
= be validated.

Mark

Begin forwarded message:

From: <= /span>"Michelle Cotton via RT" <iana-questions@iana.org>
=
Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure.
<= /span>
Date: 6 Janua= ry 2018 at 8:45:10 am AEDT

Hello,

= Following up on a thread from the end of the year.=C2=A0 Who will bring thi= s to the DNSOps working group?=C2=A0 Will someone notify us if there is an = consensus on a conclusion of what needs to be done?

Thanks in advanc= e.

--Michelle Cotton


On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote= :
I had replied to the errata. I agree it warr= ants additional
discussion, and had also suggested same. Dnsops seems ap= propriate.



The question is not to much where the attacker is= , but what DNSSEC
guarantee is provided. DNS64 imagines the client could= do its own
validation =E2=80=94 if it wanted.=C2=A0 To date, effectivel= y zero clients seem to
want to do their own DNSSEC validation.

-d=

On Dec 10, 2017, at 11:13 AM, Savolainen,= Teemu (Nokia-TECH/Tampere)
<teemu.savolainen@nokia.com> wrote:

Hi= ,

Dan Wing seem to have moved to VMWare, but cc'ing him now with= an
email address I found from an I-D..

I'm not really follow= ing IETF nowadays, so I don't know if this has
been discussed.
Also I'm not sure why ISPs couldn=E2=80=99t first verify the A respon= se's
validity and then generate AAAA response to the client as docum= ent...
but I suppose it could be considered to be more proper action to<= br>modify insecure responses than secure responses. I'm just worriedwhat happens if there's attacker between ISP and root, in which casethe IPv4 address part of the response could be modified by attacker
an= d then delivered to client in the ISP's synthetic AAAA record..

= So I cannot accept the errata straight away, but it should be
discussed = with people who are more experts on this than I am.

Best regards,
Teemu


-----Original Message-----
From: Michelle Cotton = via RT [mailto:iana-qu= estions-
comme= nt@iana.org]
Sent: 9. joulukuuta 2017 1:22
Cc: ietf@kuehlewind.net; spencerdawkins.ietf= @gmail.com;
jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere)
&= lt;teemu.sa= volainen@nokia.com>
Subject: [IANA #989438] ipv4only.arpa's d= elegation should be
insecure.

Hello,

Just checking to see = if anyone had a chance to look at this.
Dan Wing's email addressed b= ounced (dwing@cisco.co= m).

Thanks,
Michelle



On Tue Nov 28 14:43:00 2017, michelle.cotton wrote:
Hello Authors and A= rea Directors,

We have received a message pointing out an errata rep= ort that would
modify the actions that were performed for RFC7050.
https://urldefense.proofpoint.com/v2/url?u=3Dhttp= s-3A__www.rfc-
2Deditor.org_errata_eid5152&d=3DDwIGaQ&= amp;c=3DuilaK90D4TOVoH58JNXRgQ&r=3DIMDU0f3LtPMQf5XkZ06fNg&= ;m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCK= CSggUUCCU7iPuRs-
usGcL3T69Fia9gTOy4UQwhLk&e=3D

Has this repor= t been discussed?=C2=A0 Will the result be an approved
errata
report = or a new RFC?

Thanks in advance.

Michelle Cotton
Protocol = Parameters Engagement Sr. Manager



=




--=C2=A0
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Au= stralia
PHONE: +61 2 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0INTERNET: marka@i= sc.org

__________________________________________= _____
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6o= ps


____________________= ___________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--000000000000b9b592056e7cd88c-- From nobody Tue Jun 12 19:45: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 7CE36130DCC for ; Tue, 12 Jun 2018 19:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 nuTNSxvlJQ5C for ; Tue, 12 Jun 2018 19:45:06 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0244B126F72 for ; Tue, 12 Jun 2018 19:45:05 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id r15-v6so2038820wmc.1 for ; Tue, 12 Jun 2018 19:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FX7Fr0VGwGKz4f8SfoHngM0/2TVigP4Xmv6bWcVIjF0=; b=urTJKHH/RJa4sbUjtnaIZbw2vgmMG5pD9Egxlp4DwPXIOFgMbkkN12IO/O2ywt8xZU 25R6YhhjCtYSqfI/XvQVBKlfECkNBc3GqHFrPHX3cjrdIeRbX11FTgn6wZ0yvd9zuRLt 6mVrhTNjc8TmvYKaTgsmCuK01SWcmqH1fZ2hkg7oAxIiCSfQbdYfSxyfQLsVNZDqRkZT zJROt869jaromas4tq6vwQUkcsHo/l6v/eccNPdmkiqotoB9XU/xuBbDMAqbmEfoy774 4IWwzvxszwTp5mtnD65p0UqhHTbNqedKt3Htg5ctwfNPVmRcbHHPfEVTFwtcou7iyy+L TLaw== 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=FX7Fr0VGwGKz4f8SfoHngM0/2TVigP4Xmv6bWcVIjF0=; b=ApJfMwI5eCZfKPhdBMiFJ648AjtXvzehM8M778k7IunMxLKvvETuBAfSPz3skMESrI AA8vxBmBLQWfPe9JqJ7oilF2fn6FTpJ0OcAFdcvafoSDT1ap8RiBFwG6DVhX00KhGXev aOzzjqPVq4I7jDIV1lfY5P0CQhQfIYyNpTonUxcpbh3d3jnZPuKXOsAIJNsLSkqNw7TQ 9S1IQhYV09kewc0LrJ2KPKaQH43tLFFpf5OcS2l5QQxNcIh27wSDHOgJ2Kvn7fuLIlyE hHIQFSPkjzworuyJ0gcsJnnw3n1ro+CM/pRUOchpgJmnOU8V0Q+o1bP9rYwY2zl7R82j eR4Q== X-Gm-Message-State: APt69E0aHbEfkSKIjF2Ynuupw4px2wLogRqS6TOja+/oDU/8Q0rstfqA S0GDVHK+c5GDiZiIkxrTWvMP6xDirlsiXfc3r5aqx3zp X-Google-Smtp-Source: ADUXVKIktysJ7NWulXIH173qeOfrlCoLamQjtoPQNwuTM3+W9zr3+PIN7DRUze0nyH7Jx1UfboyrXckPwaFzMcslJlI= X-Received: by 2002:a1c:8312:: with SMTP id f18-v6mr2219572wmd.127.1528857903264; Tue, 12 Jun 2018 19:45:03 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> In-Reply-To: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> From: Lorenzo Colitti Date: Wed, 13 Jun 2018 11:44:51 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000003cebd1056e7cf8f0" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 02:45:17 -0000 --0000000000003cebd1056e7cf8f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ wrote: > You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) t= o tell > the CLAT the NAT64 prefix. It also provides additional advantages to the > operator to control many related aspects (see section 3 of RFC7225). > > > > 1. If the operator wants to enable 464xlat: they should hand out a > DNS64 to the CPE. > > 2. If the operator wants to disable 464xlat: they should NOT hand > out a DNS64 to the CPE. > > This doesn=E2=80=99t work, because the operator may be using RFC7225 inst= ead of > RFC7050. You need to try both in that case, and you aren=E2=80=99t provid= ing a > =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which is wha= t RFC8026 does. > But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today. > 3. If the operator uses 464xlat, they should not allow the user to > change the DNS server. > > > > > > Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the= customer to avoid changing the > DNS =E2=80=A6 > On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right? --0000000000003cebd1056e7cf8f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000003cebd1056e7cf8f0-- From nobody Tue Jun 12 20:16:10 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 EA55B130E5F; Tue, 12 Jun 2018 20:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UsmKnSv1F6RO; Tue, 12 Jun 2018 20:16:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1A5130DD7; Tue, 12 Jun 2018 20:16:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 39EEA3AB007; Wed, 13 Jun 2018 03:16:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id F07F6160072; Wed, 13 Jun 2018 03:16:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CDD19160071; Wed, 13 Jun 2018 03:16:02 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k-7RlJ-V7VcP; Wed, 13 Jun 2018 03:16:02 +0000 (UTC) Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 730A1160050; Wed, 13 Jun 2018 03:16:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> Date: Wed, 13 Jun 2018 13:15:58 +1000 Cc: dnsop , "v6ops@ietf.org WG" , Michelle Cotton via RT , Stuart Cheshire Content-Transfer-Encoding: quoted-printable Message-Id: References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 03:16:09 -0000 > On 13 Jun 2018, at 12:28 pm, David Schinazi = wrote: >=20 > Hi everyone, >=20 > Stuart and I have a draft that attempts to address these issues, = please let us know if you think it does or doesn't. >=20 > https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa >=20 > Thanks, > David Schinazi >=20 This does not meet my requirements. There is zero need for any part of = the normal DNS resolution process to know the IPV4ONLY.ARPA is special if IANA stopped signing the = zone. That would allow getaddrinfo() to be able to lookup up the AAAA records without any = intermediate software having to special case IPV4ONLY.ARPA. IPV4ONLY.ARPA would then validate = as insecure rather than as secure as it currently does. The document needs to explicitly state that the delegation for = IPV4ONLY.ARPA in ARPA MUST be insecure (no DS record). You then have other issues to deal with like not sending queries for = IPV4ONLY.ARPA to servers which have DNS64 configured or have a local IPV4ONLY.ARPA zone. These = are similar to the issues for HOME.ARPA but are at the ISP rather than the CPE. One way to handle that would be for CPE to always use the DHCP/RA DNS = servers for IPV4ONLY.ARPA and require a explicit override just for IPV4ONLY.ARPA. Another way would be for middle boxes to intercept queries but then you = have to account for anti spoofing technology TSIG, DNS COOKIE etc. DNS COOKIE just needs = the delegated servers for IPV4ONLY.ARPA to not serve any other zones. That way any DNS COOKIE = state learnt for the IP addresses of the servers for IPV4ONLY.ARPA does not impact on = IPV4ONLY.ARPA lookups. I mention TSIG because that could be used with a well known TSIG key to = defeat fragmentation attacks and because TSIG can be used between clients and recursive = servers that are not operated by the ISP. This would be one case where DNS resolution = software may want to be altered by default. This scenario is even rarer than DNSSEC. Mark >> On Jun 12, 2018, at 18:29, Mark Andrews wrote: >>=20 >> The Domain Name Reservation Considerations in RFC 7050 do not cover = whether >> a delegation should be signed or not. Due to that omission in = constructing the set >> of questions to be asked RFC 7050 fails when the client is behind a = validating resolver >> that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. >>=20 >> There are 2 pieces of work that are required. >> 1) update the list of questions that need to be asked needs to = include whether a delegation >> needs to be signed or not. >> 2) update RFC 7050 to include explicit instructions to say DO NOT = sign IPV4ONLY.ARPA. >>=20 >> Item 1 is dnsop work as far as I can see. Item 2, I think, should be = v6ops work. >>=20 >> HOME.ARPA is a example of a unsigned delegation. >> 10.IN-ADDR.ARPA is a example of a unsigned delegation. >>=20 >> There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on = the Internet >> are well known. The contents with NAT64 in using are well known = except for the >> AAAA query. The answer to that query is *expected to change*. That = answer cannot >> be validated. >>=20 >> Mark >>=20 >>> Begin forwarded message: >>>=20 >>> From: "Michelle Cotton via RT" >>> Subject: [IANA #989438] ipv4only.arpa's delegation should be = insecure. >>> Date: 6 January 2018 at 8:45:10 am AEDT >>> To: marka@isc.org >>> Reply-To: iana-questions@iana.org >>>=20 >>> Hello, >>>=20 >>> Following up on a thread from the end of the year. Who will bring = this to the DNSOps working group? Will someone notify us if there is an = consensus on a conclusion of what needs to be done? >>>=20 >>> Thanks in advance. >>>=20 >>> --Michelle Cotton >>>=20 >>>=20 >>> On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote: >>>> I had replied to the errata. I agree it warrants additional >>>> discussion, and had also suggested same. Dnsops seems appropriate. >>>>=20 >>>>=20 >>>>=20 >>>> The question is not to much where the attacker is, but what DNSSEC >>>> guarantee is provided. DNS64 imagines the client could do its own >>>> validation =E2=80=94 if it wanted. To date, effectively zero = clients seem to >>>> want to do their own DNSSEC validation. >>>>=20 >>>> -d >>>>=20 >>>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu = (Nokia-TECH/Tampere) >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an >>>>> email address I found from an I-D.. >>>>>=20 >>>>> I'm not really following IETF nowadays, so I don't know if this = has >>>>> been discussed. >>>>>=20 >>>>> Also I'm not sure why ISPs couldn=E2=80=99t first verify the A = response's >>>>> validity and then generate AAAA response to the client as = document... >>>>> but I suppose it could be considered to be more proper action to >>>>> modify insecure responses than secure responses. I'm just worried >>>>> what happens if there's attacker between ISP and root, in which = case >>>>> the IPv4 address part of the response could be modified by = attacker >>>>> and then delivered to client in the ISP's synthetic AAAA record.. >>>>>=20 >>>>> So I cannot accept the errata straight away, but it should be >>>>> discussed with people who are more experts on this than I am. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Teemu >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Michelle Cotton via RT [mailto:iana-questions- >>>>> comment@iana.org] >>>>> Sent: 9. joulukuuta 2017 1:22 >>>>> Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com; >>>>> jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere) >>>>> >>>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be >>>>> insecure. >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> Just checking to see if anyone had a chance to look at this. >>>>> Dan Wing's email addressed bounced (dwing@cisco.com). >>>>>=20 >>>>> Thanks, >>>>> Michelle >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: >>>>>> Hello Authors and Area Directors, >>>>>>=20 >>>>>> We have received a message pointing out an errata report that = would >>>>>> modify the actions that were performed for RFC7050. >>>>>>=20 >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc- >>>>>> = 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DIMDU= 0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCK= CSggUUCCU7iPuRs- >>>>>> usGcL3T69Fia9gTOy4UQwhLk&e=3D >>>>>>=20 >>>>>> Has this report been discussed? Will the result be an approved >>>>>> errata >>>>>> report or a new RFC? >>>>>>=20 >>>>>> Thanks in advance. >>>>>>=20 >>>>>> Michelle Cotton >>>>>> Protocol Parameters Engagement Sr. Manager >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jun 12 22:04: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 31C23130DDC for ; Tue, 12 Jun 2018 22:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Tmgr_StHVLD9 for ; Tue, 12 Jun 2018 22:04:26 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A07130DCE for ; Tue, 12 Jun 2018 22:04:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B01A6B3; Wed, 13 Jun 2018 07:04:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1528866261; bh=wQJO/HmiDV2JmqNrzNsTuK4Vn726oZfhSrKGJf1MgwA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GRHxTUSHlMDK8trTLtaCUeESkV2J4IcuB/7oc32DVYxRA0gziC3/UKAXD0kZUsSwX gdbxFikDn8IkYexn9FJBInKKjMFRf6rMbi7Hzfsw/RYlv1UuxuHDpE+gmgRbtWKFE2 pfinVm1IX5dJjoIIDXZm91+//XgTIRFoqmQNpK7k= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AB7D9B2; Wed, 13 Jun 2018 07:04:21 +0200 (CEST) Date: Wed, 13 Jun 2018 07:04:21 +0200 (CEST) From: Mikael Abrahamsson To: "Mudric, Dusan (Dusan)" cc: Richard Patterson , "v6ops@ietf.org list" In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB08439@AZ-US1EXMB03.global.avaya.com> Message-ID: References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB08439@AZ-US1EXMB03.global.avaya.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] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 05:04:30 -0000 On Tue, 12 Jun 2018, Mudric, Dusan (Dusan) wrote: > lease. Considering the lease will not be RELEASE-d, the server will not > offer the lease for the new solicitation. The client should use Server Hm, I am not an DHCPv6 expert, but in my experience if I power off a device with an active lease, power it on again, it comes up again and does SOLICIT, it will get the same prefix back that it had before the power off (it does not provide any prefix information in the solicit). What am I missing here? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jun 12 23:42: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 B49B4130DFA for ; Tue, 12 Jun 2018 23:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSrdsiUulCzZ for ; Tue, 12 Jun 2018 23:42:10 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D136B130DFB for ; Tue, 12 Jun 2018 23:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528872127; x=1529476927; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=K1kFeZQe9QBhMk+NRIqSQ yJ7/VjTry/PZKza/2kWq8I=; b=IZidqV19hSLMFPN3gMbwku0fj8h2Pv/qWY1sw Yv9DVS7yMrAbYW9moovmgYW7yYL5BUqkvFiEP8VZVEw+TRChHN/9afSM8GTrQR7p NYw3gpcOqb6kcZeFCwrD7QLX761W0BH1OdFg0yI6NIelQwDSU3cpIKtV9ooe/8DD nMPm8Y= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:42:07 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:42:05 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788525.msg for ; Wed, 13 Jun 2018 08:42:05 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 08:42:05 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 13 Jun 2018 08:42:02 +0200 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio , Message-ID: <9B8E8D64-D3BC-474A-A1AC-D86D21ABB2DE@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 06:42:16 -0000 Hi Alejandro, Thanks for the inputs/questions. Some responses below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: martes, 12 de junio de 2018, 22:55 Para: Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas Hello, First at all, I've read all the thread and I think this is a very usefu= l discussion. I work in a cable operator and I think 464XLAT is a great idea to be in= cluded in CPEs. So, everything related to that is interesting for me. -> You're not alone, many people is considering 464XLAT, so welcome to the = club. I have some questions: 1- Why the RFC8026 can include Option Codes for many transition methods= and not for 464XLAT? -> I've looked at many option codes for DHCPv6 options, and I've seen that = is done without any problem when needed in other IETF documents, so I clear= ly believe we should do that, so we can have a priority and on/off switch f= or every protocol. As Barbara said operators should be able to choose if th= ey want the CE to use a mechanism or not. 2- Why we can't have an alternative to RFC7050 and RFC7225? -> We proposed some time ago a mechanism based in a new DHCPv6 option but w= as not accepted. The reason most of the time this doesn't happen is that op= erators aren't contributing to IETF to tell "yes I need this (or I don't ne= ed that)". Is not an issue for the scope of this document, but I agree, it = will be good to have it. That document is expired, but still available if y= ou want to take a look (https://tools.ietf.org/html/draft-li-intarea-nat64-= prefix-dhcp-option-01). Note that in any case, this is not being discussed = now (and is not a topic for this WG). 3- What if some CPEs works fine with some RFCs and not with other? Shou= ldn't be better to have alternatives? It's really common to have many Bugs = in CPEs specially with new protocols. They can say they support some RFC bu= t it doesn't work and you will need to wait some months (if you're lucky) t= o get the solution. -> Not sure to understand your point here. However, what we are trying, pre= cisely, is to make sure that the CPEs intended for the transition (supporti= ng IPv4 while we need it, on top of IPv6-only networks), follow a single do= cument, the same way we have RFC7084 when no transition at all is needed. 4- In our cablemodems we doesn't allow to customer to modify DNS config= uration but, what about if customer change cablemodem to Bridge Mode and co= nnects it's own CPE? This is a usual case where you can't control DNS confi= guration but you still want to use 464XLAT. -> Right, this is one more reason to have the support of 464XLAT without DN= S64, and thus an RFC8026 option to prioritize and switch on/off the mechani= sm. =20 =20 Thanks and Regards, =20 ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Philip Homburg" , v6ops@ietf.org Enviados: Martes, 12 de Junio 2018 7:48:07 Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v= 6ops-transition-ipv4aas =20 I think my earlier email to Lorenzo provides answers to most of this ..= . but =20 > I see your point, but > what an operator need is a "100% sure" way to make sure that they > can tell the CPE to not use a specific transition mechanism (whic= h > for the other mechanisms we have with RFC8026). >=20 > So, assuming that DNS64 is only there if combined with NAT64 is > not "safe 100%" because if using CLAT, you can avoid having a DNS= 64 > (this is the one that breaks DNSSEC, in case I wrote it incorrect= ly > before). =20 I'm saying that if an operator uses DNS64 to signal the presence of= NAT64, then that is a reliable signal that doesn't need an additional DHCP= option. =20 So if is safe for a CPE to just do RFC7050, because if DNS64 is det= ected, you can be sure that the operator wants the CPE to use NAT64. =20 As said, you can use the CLAT w/o DNS64, so it is not a safe way to det= ect the CPE should use or not the NAT64. =20 > But if the user changed the DNS in the CPE (which is quite common= ), > there will not be DNS64 and still may be the ISP want to have the > CLAT running, because is using that for the IPv4 service for that > particular customer. =20 Yeah, what if the user changes settings? Maybe the CPE has a way to= force=20 NAT64 on. What do you do then? All bets are off when users start ch= anging settings. =20 An operator wants to make it as proof as possible to user changes. A us= er has no interest in changing the status of NAT64 (probably they don't kno= w what it means), but they have interested in changing the DNS, because man= y apps or web sites tell them to change it. =20 In the context of RFC7050, the CPE can opt to use the original reso= lvers provided by upstream to figure out the translation prefix. =20 Note that if the CPE uses resolvers configured by the user for RFC7= 050, then is it quite possible that the translation prefix is not discovered = (for example if the user configures a well known public resolver). Or worse,=20 the user may configure a DNS64 resolver that uses a different prefi= x. =20 Right, that's one case, using an alternative DNS64, which will bring al= ternative NAT64, unless/or the operator is using PCP for the NAT64 provisio= ning. =20 > If you agree that the CPE may request a PCP option, etc., then > request the S46, I think you are in agreement that we need the S4= 6 > priority option codes for all the mechanism that we are asking to > be supported by the CPE, right? =20 To the extent that RFC8026 is incomplete, that should be fixed. How= ever as Section 2.2 describes, what S46 offers can be done already be done = by the DHCPv6 server. So S46 just provides a relative priority of differen= t mechanisms, not an on/off switch for NAT64. =20 What it makes this work is the combination of RFC8026 and the CPE behav= ior. The idea is to have a S46 option to provide a priority in a list of "p= ossible" transition mechanism to a given CPE. If the operator doesn't want = that a specific CPE uses NAT64, then the S46 will not contain that option, = so the CE will not use it, because will not have a match (even if the CPE i= s able to use 464XLAT). Not sure if this explanation clarify it ? I'm worki= ng on the precise text for that in the ID ... =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jun 12 23:50: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 4328E130EA0 for ; Tue, 12 Jun 2018 23:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHoitb8QVNLK for ; Tue, 12 Jun 2018 23:50:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37422130DFB for ; Tue, 12 Jun 2018 23:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528872626; x=1529477426; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=ONHdqg8l/DT8A6C7IMB7S7 twd4EwnmSo80Ev3/HCaCY=; b=RYJtTxnHfCsG123REWJxzFO49IV7FuWqkS7PI+ sjjYi4EF1JiiLbCYsVMWiVfkDu+cQK/s2J9fYbqVnsGwt4/ydUCJq2n0Ked6VyLw Cy+kKaxDR1zoO+U68VKr+Q7oaCevl/ImuKMIFeIQ2OWxaUfJoJ/MX0kL6y82Y9Uj 88Mwo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:50:26 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 08:50:26 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788527.msg for ; Wed, 13 Jun 2018 08:50:25 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 08:50:25 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Wed, 13 Jun 2018 08:50:21 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Message-ID: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611724621_300309036" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 06:50:34 -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_3611724621_300309036 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize, w= hen an ISP supports several transition mechanisms. =20 RFC8026 key aspect is priority. If we don=E2=80=99t add an option code for = 464XLAT, then it can=E2=80=99t be managed the same way. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ wrote: You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225). =20 1. If the operator wants to enable 464xlat: they should hand out a DN= S64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does. =20 But it's the same problem again: what's the use case for this DHCPv6 option= ? An operator that's using RFC7225 has an easy way to tell the CPE not to d= o 464xlat: don't hand out the prefix64 to those CPEs. So this is already po= ssible today. =20 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. =20 =20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6 =20 On an operator-managed CPE, you can. On a user-managed CPE, you can't. But = on such a CPE you probably shouldn't be disabling 464xlat. If the user want= s to use it, it's their CPE, right? _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611724621_300309036 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Lorenzo, you=E2=80=99re missing the key aspect: Being able to= prioritize, when an ISP supports several transition mechanisms.=

 

RFC8026 key aspect is priority. = If we don=E2=80=99t add an option code for 464XLAT, then it can=E2=80=99t b= e managed the same way.


Regards,

Jordi<= o:p>

 

 

 

De: v6ops <v6ops-bounces@i= etf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.i= etf.org>
Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45
<= b>Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC:= "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transi= tion-ipv4aas

 

On Tue, Jun 12, 2018 at 7:40 PM JORDI = PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP= (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional a= dvantages to the operator to control many related aspects (see section 3 of= RFC7225).

 = ;

1.       I= f the operator wants to disable 464xlat: they should NOT hand out a DN= S64 to the CPE.

This doesn=E2=80=99t work, because the operator may be using RFC72= 25 instead of RFC7050. You need to try both in that case, and you aren=E2= =80=99t providing a =E2=80=9Cpriority=E2=80=9D to a possible list of mechan= isms, which is what RFC8026 does.

 

But it's the sam= e problem again: what's the use case for this DHCPv6 option? An operator th= at's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't= hand out the prefix64 to those CPEs. So this is already possible today.

&n= bsp; 

3.       If the o= perator uses 464xlat, they should not allow the user to change the DNS serv= er.

 = ;

 <= /span>

Let=E2=80= =99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the customer t= o avoid changing the DNS =E2=80=A6

 

On an o= perator-managed CPE, you can. On a user-managed CPE, you can't. But on such= a CPE you probably shouldn't be disabling 464xlat. If the user wants to us= e it, it's their CPE, right?

_______________________________________= ________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/lis= tinfo/v6ops


**************************************= ********
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611724621_300309036-- From nobody Wed Jun 13 00:38: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 DB0BA130E03 for ; Wed, 13 Jun 2018 00:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F607diOFm-18 for ; Wed, 13 Jun 2018 00:38:39 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694AD130DF9 for ; Wed, 13 Jun 2018 00:38:39 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w7-v6so1590514wrn.6 for ; Wed, 13 Jun 2018 00:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKw9QVgygb8DXsYyyLFiIlBIaJsOUC0mWzVEqK8Pbt0=; b=Z6zdJpx+s34BZg03jGVUII7xBU7dBsYV+GjdPNvmmlMnBq8zU+LSraNurtMf97VBom 2ke0JPZBKgwrVr7mSfs2p/c7pVkrMQGrC3lXAo6t8+949h78VGnhO2bUWsrrcqjDaRsX lNqxbguB1+WfAkyux1IphdoYhvEuVHu9Ue+3+wvSzYquuwb/vAjVK71l3xw1BxKeE97g sGnhDjzG9FkHig4qGeYjo9vxn1nVrr5V6fCQ4aLrhJxDb1iqinUm8bstEuypt076m4vS TdwDo789HRZsU8I09+avyZ3INv0O7Wi8tuTxgFAKdv0a38eJHh5SmhdtoAlUp5gq3PgH XQgw== 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=dKw9QVgygb8DXsYyyLFiIlBIaJsOUC0mWzVEqK8Pbt0=; b=YCTwjTlYw/QPM7RnruRd8WB2lf6syx+jKDsMv8WPVuWYDt4c3DchNfQLOAmV4mKsqm Ju0etvnCJjGIsP8uGuY2II+VNWtpuEcHcQ+kKqwoSzZmT/pA5mqokg/P2bChVsX31AKU 3eulIgCjVIyV/7DHfvOXelMYz9MxLpLm4PZEho9pjaeYhrDzCq3S6RPkvjtJW6t96PFi ZKljsD7+MDH6gs0REXSrSr4AyqWSf3zGwPSElV/O7gH/ulVLWnX1UHcSJ3J1nS9Cpo0o Qu3hYSJS6Ut80/u8i7G0/UFducWp9nk9u+d0+2kuRjwqcPH1w2T8XeeY0lelLo/jimFJ exRw== X-Gm-Message-State: APt69E1THYDazBxaaoxorNRizgQJ/Zi5qL16zsz7u6b/MeVSHZRqNgAN REnQ7g5/j7O3lDvQKPJVLZptXTkV3KskmAzN9UMqYNeaSOM= X-Google-Smtp-Source: ADUXVKI3ELa4SnotFK3r6DP00UOeW5b4NDjzBy1ivCxj0Z4oxDMQiUmd7npFuFj3ZiBTKJ1tbldufPVk1wFlbDaHjLw= X-Received: by 2002:adf:d08b:: with SMTP id y11-v6mr3272009wrh.152.1528875517531; Wed, 13 Jun 2018 00:38:37 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> From: Lorenzo Colitti Date: Wed, 13 Jun 2018 16:38:25 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000216733056e811230" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 07:38:45 -0000 --000000000000216733056e811230 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-) On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ wrote: > Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize,= when an > ISP supports several transition mechanisms. > > > > RFC8026 key aspect is priority. If we don=E2=80=99t add an option code fo= r > 464XLAT, then it can=E2=80=99t be managed the same way. > > > Regards, > > Jordi > > > > > > > > *De: *v6ops en nombre de Lorenzo Colitti > > *Fecha: *mi=C3=A9rcoles, 13 de junio de 2018, 4:45 > *Para: * > *CC: *"v6ops@ietf.org WG" > *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in > draft-ietf-v6ops-transition-ipv4aas > > > > On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > > You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) t= o tell > the CLAT the NAT64 prefix. It also provides additional advantages to the > operator to control many related aspects (see section 3 of RFC7225). > > > > 1. If the operator wants to enable 464xlat: they should hand out a > DNS64 to the CPE. > > 2. If the operator wants to disable 464xlat: they should NOT hand > out a DNS64 to the CPE. > > This doesn=E2=80=99t work, because the operator may be using RFC7225 inst= ead of > RFC7050. You need to try both in that case, and you aren=E2=80=99t provid= ing a > =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which is wha= t RFC8026 does. > > > > But it's the same problem again: what's the use case for this DHCPv6 > option? An operator that's using RFC7225 has an easy way to tell the CPE > not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is > already possible today. > > > > 3. If the operator uses 464xlat, they should not allow the user to > change the DNS server. > > > > > > Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the= customer to avoid changing the > DNS =E2=80=A6 > > > > On an operator-managed CPE, you can. On a user-managed CPE, you can't. Bu= t > on such a CPE you probably shouldn't be disabling 464xlat. If the user > wants to use it, it's their CPE, right? > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > --000000000000216733056e811230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That goes back to my earlier point of that from a technica= l perspective 464xlat is pretty much the worst of the transition mechanisms= . I don't think we should be recommending running it on wireline at all= , let alone prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET = MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

Lorenzo, you=E2=80=99re missing the key aspect: Being able to pr= ioritize, when an ISP supports several transition mechanisms.=

=C2=A0=

RFC8026 key aspect i= s priority. If we don=E2=80=99t add an option code for 464XLAT, then it can= =E2=80=99t be managed the same way.

=
Re= gards,

Jor= di

= =C2=A0

=C2=A0

=C2=A0

De: v6ops <v6ops-bounces@ietf.org&= gt; en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org>Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45
Para: &l= t;jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG"= ; <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in = draft-ietf-v6ops-transition-ipv4aas

=C2=A0

You don=E2=80=99t need RFC7050 neither DNS64, you c= an use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides ad= ditional advantages to the operator to control many related aspects (see se= ction 3 of RFC7225).

=C2=A0

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operator wants to enable 464xlat: they should hand out a DNS= 64 to the CPE.

2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operator = wants to disable=C2=A0464xlat: they should NOT hand out a DNS64 to the CPE.=

This doesn=E2=80=99t work, because the operator may = be using RFC7225 instead of RFC7050. You need to try both in that case, and= you aren=E2=80=99t providing a =E2=80=9Cpriority=E2=80=9D to a possible li= st of mechanisms, which is what RFC8026 does.

=C2=A0

But it's the same problem again: what's the use case = for this DHCPv6 option? An operator that's using RFC7225 has an easy wa= y to tell the CPE not to do 464xlat: don't hand out the prefix64 to tho= se CPEs. So this is already possible today.

=C2=A0=C2=A0=

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operator uses 464xlat, they should not allow the user t= o change the DNS server.

=C2=A0<= /p>

=C2=A0

Let=E2=80=99s be realistic. You can=E2=80=99t= =E2=80=9Cforce=E2=80=9D the customer to avoid changing the DNS =E2=80=A6

=C2=A0

On an operator-managed CPE, you= can. On a user-managed CPE, you can't. But on such a CPE you probably = shouldn't be disabling 464xlat. If the user wants to use it, it's t= heir CPE, right?

______________________________________________= _ v6ops mailing list v6= ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /u>


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulin= tel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--000000000000216733056e811230-- From nobody Wed Jun 13 00:53: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 84A2E130E0E for ; Wed, 13 Jun 2018 00:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT2wt8Tg4x-q for ; Wed, 13 Jun 2018 00:52:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F79130E04 for ; Wed, 13 Jun 2018 00:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528876372; x=1529481172; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=H3QZCkeAN+TzqhivJkajU+ Q/5xJQRQd1YxWi9RmsWrY=; b=HTmZx9tIAem73Jj4d4w5wsvb6PCA1uqiVd6+qt T2xAyJKKkoJynBnWaglP//+9nLTWag2I52Hco2pCplz+aNIJvH5iXokAoB5vWAc+ JNyWWu5U5vhohpoWnn6sRDZpxf/C+KfbLOrHs7X+V1Ke9N4BvScylXbjIokX4DF1 XEgto= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 09:52:52 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 09:52:51 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788564.msg for ; Wed, 13 Jun 2018 09:52:51 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 09:52:51 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 09:52:48 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Message-ID: <8F8C6328-7A18-4399-A0DE-19EDB280E238@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611728368_1231216232" Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 07:53:03 -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_3611728368_1231216232 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I don=E2=80=99t think is fair to judge if 464XLAT is better or worse than o= ther transition mechanism because it was not included in RFC8026 =E2=80=A6 =20 By the way, I realized also that some CLAT implementations are taking by de= fault the NAT64 WKP (64:ff9b::/96, and other prefixes can be manually confi= gured by GUI or CLI), so in fact, one more example that DNS64 is not needed= and you may not need to implement at all RFC7050 neither RFC7225, so one m= ore reason for requiring this change. =20 Note that I=E2=80=99m not saying is good a CLAT with by default the WKP NAT= 64, because it means the operator is forced to use the WKP, however, I =E2= =80=98ve the feeling that in 99% of the NAT64 deployments is done that way = ... Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 9:39 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 That goes back to my earlier point of that from a technical perspective 464= xlat is pretty much the worst of the transition mechanisms.. I don't think = we should be recommending running it on wireline at all, let alone prioriti= zing it over something else .:-) =20 On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ wrote: Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize, w= hen an ISP supports several transition mechanisms. =20 RFC8026 key aspect is priority. If we don=E2=80=99t add an option code for = 464XLAT, then it can=E2=80=99t be managed the same way. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ wrote: You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225). =20 1. If the operator wants to enable 464xlat: they should hand out a DN= S64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does. =20 But it's the same problem again: what's the use case for this DHCPv6 option= ? An operator that's using RFC7225 has an easy way to tell the CPE not to d= o 464xlat: don't hand out the prefix64 to those CPEs. So this is already po= ssible today. =20 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. =20 =20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6 =20 On an operator-managed CPE, you can. On a user-managed CPE, you can't. But = on such a CPE you probably shouldn't be disabling 464xlat. If the user want= s to use it, it's their CPE, right? _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611728368_1231216232 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I don=E2=80=99t think is fair to judge if 464XLAT is better o= r worse than other transition mechanism because it was not included in RFC8= 026 =E2=80=A6

 

By the= way, I realized also that some CLAT implementations are taking by default = the NAT64 WKP (64:ff9b::/96, and other prefixes can be manually configured = by GUI or CLI), so in fact, one more example that DNS64 is not needed and y= ou may not need to implement at all RFC7050 neither RFC7225, so one more re= ason for requiring this change.

<= span lang=3DEN-US style=3D'mso-fareast-language:EN-US'> 

Note that I=E2=80=99m not saying is good a CLAT with by default t= he WKP NAT64, because it means the operator is forced to use the WKP, howev= er, I =E2=80=98ve the feeling that in 99% of the NAT64 deployments is done = that way ...


Regards,

Jordi<= /span>

<= o:p> 

 

 

De: v6ops <v6ops-bounces@ietf.org&g= t; en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org&g= t;
Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 9:39
Para: <= /b><jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC: &quo= t;v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6o= ps] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4= aas

 

That goes back to my earlier point of that from a technic= al perspective 464xlat is pretty much the worst of the transition mechanism= s.. I don't think we should be recommending running it on wireline at all, = let alone prioritizing it over something else .:-)

 

On Wed, Jun 13, 2018 at= 3:50 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:=

Lorenzo, you=E2=80=99re mis= sing the key aspect: Being able to prioritize, when an ISP supports several= transition mechanisms.

 

RFC8026 key aspect is priority. If we don=E2=80=99t add an opt= ion code for 464XLAT, then it can=E2=80=99t be managed the same way.


Regards,

Jordi

 <= /p>

 <= /o:p>

 <= /o:p>

De: v6ops <v6o= ps-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@d= marc.ietf.org>
Fecha: mi=C3=A9rcoles, 13 de junio de 2018,= 4:45
Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.org>CC: "v6op= s@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 = to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas=

 

On Tue, Jun 12, 2018 at 7:40 PM JORDI PAL= ET MARTINEZ <jordi.palet=3D40consulintel..es@dmarc.ietf.org> wrote:

You don= =E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell th= e CLAT the NAT64 prefix. It also provides additional advantages to the oper= ator to control many related aspects (see section 3 of RFC7225).=

 

1.  =      If the operator wants to= enable 464xlat: they should hand out a DNS64 to the CPE.=

2. &nbs= p;     If the operator wants = to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn=E2= =80=99t work, because the operator may be using RFC7225 instead of RFC7050.= You need to try both in that case, and you aren=E2=80=99t providing a =E2= =80=9Cpriority=E2=80=9D to a possible list of mechanisms, which is what RFC8026 does.

 

But it's the same problem again: what's the use case for this D= HCPv6 option? An operator that's using RFC7225 has an easy way to tell the = CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this i= s already possible today.

  

3.     =   If the operator uses 464xlat, they should = not allow the user to change the DNS server.

 

 

Let=E2=80=99s be realistic. You can=E2= =80=99t =E2=80=9Cforce=E2=80=9D the customer to avoid changing the DNS =E2= =80=A6

 

On an op= erator-managed CPE, you can. On a user-managed CPE, you can't. But on such = a CPE you probably shouldn't be disabling 464xlat. If the user wants to use= it, it's their CPE, right?

_______________________________________________ v6ops mailing li= st v6ops@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/v6ops


*******************************************= ***
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.esThe IPv6 Company

This electronic message contains information whic= h may be privileged or confidential. The information is intended to be for = the exclusive use of the individual(s) named above and further non-explicil= ty authorized disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited and will be considered a criminal offense. If you are not the int= ended recipient be aware that any disclosure, copying, distribution or use = of the contents of this information, even if partially, including attached = files, is strictly prohibited, will be considered a criminal offense, so yo= u must reply to the original sender to inform about this communication and = delete it.

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


********************************************** IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611728368_1231216232-- From nobody Wed Jun 13 01:01: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 1E377130DFC for ; Wed, 13 Jun 2018 00:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zzH15nthgYV for ; Wed, 13 Jun 2018 00:58:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A75130E02 for ; Wed, 13 Jun 2018 00:58:48 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 511EF3AB007; Wed, 13 Jun 2018 07:58:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 137BC160048; Wed, 13 Jun 2018 07:58:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E217B16006C; Wed, 13 Jun 2018 07:58:47 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FYzjVQCJVbf2; Wed, 13 Jun 2018 07:58:47 +0000 (UTC) Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 121C6160048; Wed, 13 Jun 2018 07:58:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <8F8C6328-7A18-4399-A0DE-19EDB280E238@consulintel.es> Date: Wed, 13 Jun 2018 17:58:44 +1000 Cc: Lorenzo Colitti , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <8F8C6328-7A18-4399-A0DE-19EDB280E238@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 07:58:52 -0000 > On 13 Jun 2018, at 5:52 pm, JORDI PALET MARTINEZ = wrote: >=20 > I don=E2=80=99t think is fair to judge if 464XLAT is better or worse = than other transition mechanism because it was not included in RFC8026 = =E2=80=A6 > =20 > By the way, I realized also that some CLAT implementations are taking = by default the NAT64 WKP (64:ff9b::/96, and other prefixes can be = manually configured by GUI or CLI), so in fact, one more example that = DNS64 is not needed and you may not need to implement at all RFC7050 = neither RFC7225, so one more reason for requiring this change. > =20 > Note that I=E2=80=99m not saying is good a CLAT with by default the = WKP NAT64, because it means the operator is forced to use the WKP, = however, I =E2=80=98ve the feeling that in 99% of the NAT64 deployments = is done that way ... >=20 > Regards, > Jordi Even if they are currently, in the later stages of the transition = ISP=E2=80=99s may want to outsource ipv4aas. When that is done the WKP = won=E2=80=99t work. You need a specific prefix to direct the traffic to = the outsource operator. Outsourcing is possible for all the ipv4aas mechanisms AFAIK. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 13 01:05: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 19DDB130F14 for ; Wed, 13 Jun 2018 01:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo4shmJnS3mW for ; Wed, 13 Jun 2018 01:04:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7E9130EF1 for ; Wed, 13 Jun 2018 01:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528877081; x=1529481881; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=O8BETqqX5EE5D3mmVQEOGe+7absxiq051wXQE00SesU=; b=MUP0MvQbzcAMz lebQ8hqor6/607t/zfGLaDBhbVrVLyr5CZpFFu2XCJUVHSq7R4cNTKMFWreRhpqw zM1ohOIH1Bwl+Ada7+wO9/FHuPFq84/codl5Y545Zi+yYpwdj8lSM4QclL4fweg6 maPgrx9BOZZc1Nu0kCtJiL+RHy6tVE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 10:04:41 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 10:04:41 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788571.msg for ; Wed, 13 Jun 2018 10:04:41 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 10:04:41 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 10:04:38 +0200 From: JORDI PALET MARTINEZ To: Mark Andrews CC: "v6ops@ietf.org WG" , Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <8F8C6328-7A18-4399-A0DE-19EDB280E238@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 08:04:55 -0000 Hi Mark, Totally agree, in fact I've introduced several "outsourcing" scenarios for = NAT64 in draft-palet-v6ops-nat64-deployment. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mark Andrews Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 10:00 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org WG" , Lorenzo Colitti Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 > On 13 Jun 2018, at 5:52 pm, JORDI PALET MARTINEZ wrote: >=20 > I don=E2=80=99t think is fair to judge if 464XLAT is better or worse = than other transition mechanism because it was not included in RFC8026 =E2= =80=A6 > =20 > By the way, I realized also that some CLAT implementations are taking= by default the NAT64 WKP (64:ff9b::/96, and other prefixes can be manually= configured by GUI or CLI), so in fact, one more example that DNS64 is not = needed and you may not need to implement at all RFC7050 neither RFC7225, so= one more reason for requiring this change. > =20 > Note that I=E2=80=99m not saying is good a CLAT with by default the W= KP NAT64, because it means the operator is forced to use the WKP, however, = I =E2=80=98ve the feeling that in 99% of the NAT64 deployments is done that= way ... >=20 > Regards, > Jordi =20 Even if they are currently, in the later stages of the transition ISP= =E2=80=99s may want to outsource ipv4aas. When that is done the WKP won=E2= =80=99t work. You need a specific prefix to direct the traffic to the outs= ource operator. =20 Outsourcing is possible for all the ipv4aas mechanisms AFAIK. =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 13 01:33:20 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 6C0D2130E05; Wed, 13 Jun 2018 01:33:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152887879737.15082.16890566747315339823@ietfa.amsl.com> Date: Wed, 13 Jun 2018 01:33:17 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 08:33:18 -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 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-02.txt Pages : 20 Date : 2018-06-13 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. In order to be able to prioritize, in a uniform way, among all the transition mechanisms, and to enable the service provider to enable/ disable them, this document updates RFC8026. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 13 01:38: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 99214130E05 for ; Wed, 13 Jun 2018 01:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjekQ-I2wL2b for ; Wed, 13 Jun 2018 01:38:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D78130E0A for ; Wed, 13 Jun 2018 01:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528879107; x=1529483907; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=XPKHl5Xe ghuRp4tAWellUT1A3ExlpjQduy0zfMCpldY=; b=W5R8Q1k09VKh9tm0kkNXcsd8 XY9N5UIWx+RSN+KqpchBMTUOVNLf5e857MahcBzXP9yIvuerWs9PI4FM61ZfU0fV EUXIQPmvidF5dtIw5D8HTsF7mHMbX0tFmRDmqhPleWaMV6ukH6oBaFIDFeb49xAc XbRaf2Rkebk91CTpGFc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 10:38:27 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 10:38:26 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788586.msg for ; Wed, 13 Jun 2018 10:38:26 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 10:38:26 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 10:38:21 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-02.txt References: <152887879737.15082.16890566747315339823@ietfa.amsl.com> In-Reply-To: <152887879737.15082.16890566747315339823@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 08:38:34 -0000 Hi all, This is an updated version (-02) of=20 https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Main changes are depicted in ANNEX D: 1. TRANS requirements reworked in order to increase operator control and allow gradual transitioning from dual-stack to IPv6-only on specific customers. 2. New TRANS requirement so all the supported transition mechanisms are disabled by default, in order to facilitate the operator management. 3. New TRANS requirement in order to allow turning on/off each transition mechanism by the user. 4. Clarification on how to obtain multiple /64 for 464XLAT. 5. S46 priority update to RFC8026 for including 464XLAT and related changes in several sections. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 10:33 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-02.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-02.txt Pages : 20 Date : 2018-06-13 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. =20 In order to be able to prioritize, in a uniform way, among all the transition mechanisms, and to enable the service provider to enable/ disable them, this document updates RFC8026. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-02 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -02 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 13 02:12: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 E79B1130E14 for ; Wed, 13 Jun 2018 02:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9VNGR914pht for ; Wed, 13 Jun 2018 02:11:57 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F87A130E0A for ; Wed, 13 Jun 2018 02:11:56 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-41-164.kabelnet.hu [79.121.41.164]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5D9BjOO081302 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 13 Jun 2018 11:11:50 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-164.kabelnet.hu [79.121.41.164] claimed to be [192.168.1.114] To: v6ops@ietf.org References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Wed, 13 Jun 2018 11:11:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------145621110D1AA7D5F60123BD" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.164; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:12:03 -0000 This is a multi-part message in MIME format. --------------145621110D1AA7D5F60123BD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Lorenzo, I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective." We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist. Which of them do you mean to be better than 464XLAT? What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.) I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions. Best regards, Gbor Lencse [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, /IEICE Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf 6/13/2018 9:38 AM keltezssel, Lorenzo Colitti rta: > That goes back to my earlier point of that from a technical > perspective 464xlat is pretty much the worst of the transition > mechanisms.. I don't think we should be recommending running it on > wireline at all, let alone prioritizing it over something else .:-) > > On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ > > wrote: > > Lorenzo, youre missing the key aspect: Being able to prioritize, > when an ISP supports several transition mechanisms. > > RFC8026 key aspect is priority. If we dont add an option code for > 464XLAT, then it cant be managed the same way. > > > Regards, > > Jordi > > *De: *v6ops > en nombre de Lorenzo Colitti > > > *Fecha: *mircoles, 13 de junio de 2018, 4:45 > *Para: * > > *CC: *"v6ops@ietf.org WG" > > *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in > draft-ietf-v6ops-transition-ipv4aas > > On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ > > wrote: > > You dont need RFC7050 neither DNS64, you can use PCP > (RFC7225) to tell the CLAT the NAT64 prefix. It also provides > additional advantages to the operator to control many related > aspects (see section 3 of RFC7225). > > 1.If the operator wants to enable 464xlat: they should hand > out a DNS64 to the CPE. > > 2.If the operator wants to disable 464xlat: they should NOT > hand out a DNS64 to the CPE. > > This doesnt work, because the operator may be using RFC7225 > instead of RFC7050. You need to try both in that case, and you > arent providing a priority to a possible list of > mechanisms, which is what RFC8026 does. > > But it's the same problem again: what's the use case for this > DHCPv6 option? An operator that's using RFC7225 has an easy way to > tell the CPE not to do 464xlat: don't hand out the prefix64 to > those CPEs. So this is already possible today. > > 3.If the operator uses 464xlat, they should not allow the user > to change the DNS server. > > Lets be realistic. You cant force the customer to avoid > changing the DNS > > On an operator-managed CPE, you can. On a user-managed CPE, you > can't. But on such a CPE you probably shouldn't be disabling > 464xlat. If the user wants to use it, it's their CPE, right? > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the exclusive use of the individual(s) named above and further > non-explicilty authorized disclosure, copying, distribution or use > of the contents of this information, even if partially, including > attached files, is strictly prohibited and will be considered a > criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, > is strictly prohibited, will be considered a criminal offense, so > you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------145621110D1AA7D5F60123BD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

Gbor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf


6/13/2018 9:38 AM keltezssel, Lorenzo Colitti rta:
That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms.. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

Lorenzo, youre missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

RFC8026 key aspect is priority. If we dont add an option code for 464XLAT, then it cant be managed the same way.


Regards,

Jordi

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Fecha: mircoles, 13 de junio de 2018, 4:45
Para: <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel..es@dmarc.ietf.org> wrote:

You dont need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

1. If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2. If the operator wants to disable464xlat: they should NOT hand out a DNS64 to the CPE.

This doesnt work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you arent providing a priority to a possible list of mechanisms, which is what RFC8026 does.

But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

3. If the operator uses 464xlat, they should not allow the user to change the DNS server.

Lets be realistic. You cant force the customer to avoid changing the DNS

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



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

--------------145621110D1AA7D5F60123BD-- From nobody Wed Jun 13 02:21:09 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 D24A21310B1 for ; Wed, 13 Jun 2018 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD_B48pqU61h for ; Wed, 13 Jun 2018 02:20:53 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D17131072 for ; Wed, 13 Jun 2018 02:20:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5D9KjWd045214; Wed, 13 Jun 2018 11:20:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1795420318D; Wed, 13 Jun 2018 11:20:45 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 092B320318B; Wed, 13 Jun 2018 11:20:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5D9KioG018928; Wed, 13 Jun 2018 11:20:44 +0200 To: Jen Linkova Cc: V6 Ops List References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> From: Alexandre Petrescu Message-ID: <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> Date: Wed, 13 Jun 2018 11:20:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:21:08 -0000 Le 27/04/2018 à 05:12, Jen Linkova a écrit : > On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu > wrote: >> Even us, at IETF, whenever we write a new hot Internet Draft we put it >> on an IPv4 website first. > Actually we we don't. > >> (I guess datatracker is not reachable on IPv6, >> just guess.) > > I've just completely disabled IPv4 on my workstation and > https://datatracker.ietf.org works just fine (I tested browsing the > drafts and some links on WG Chair dashboard). I have just used an IPv6 linux laptop on an IPv6 cellular link that gives no IPv4. The laptop connects ok to https://ietf.org, tools.ietf.org. I have even tried to register for the next meeting. I went with the process up to filling the data, but stopped there. There are however some websites that dont work, like github.com. Many people use github for IETF work like drafts, charters, etc. Alex From nobody Wed Jun 13 03:13: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 8BCB1130E32; Wed, 13 Jun 2018 03:13:13 -0700 (PDT) X-Quarantine-ID: <4niX1e836TMZ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4niX1e836TMZ; Wed, 13 Jun 2018 03:13:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C0E130E14; Wed, 13 Jun 2018 03:13:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fT2lY-0000IHC; Wed, 13 Jun 2018 12:12:36 +0200 Message-Id: To: v6ops@ietf.org Cc: David Schinazi Cc: Mark Andrews , Stuart Cheshire , Michelle Cotton via RT , dnsop From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> In-reply-to: Your message of "Tue, 12 Jun 2018 19:28:16 -0700 ." <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> Date: Wed, 13 Jun 2018 12:12:28 +0200 Archived-At: Subject: Re: [v6ops] [DNSOP] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 10:13:14 -0000 >https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa > >From Section 6.2: 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment. Regardless of any manual client DNS configuration, DNS overrides configured by VPN client software, or any other mechanisms that influence the choice of the client's recursive resolver address(es) (including client devices that run their own local recursive resolver and use the loopback address as their configured recursive resolver address) all queries for 'ipv4only.arpa' and any subdomains of that name MUST be sent to the recursive resolver learned from the network via IPv6 Router Advertisement Options for DNS Configuration [RFC6106] or via DNS Configuration options for DHCPv6 [RFC3646]. First we introduce ipv4only.arpa as a hack to avoid creating/deploying a suitable mechanism to communicate the NAT64 translation prefix. That's fine with me. But when that hack then requires changes to every possible DNS stub resolver implementation in the world, there is something seriously wrong. So if this in indeeed required to make RFC7050 work then it is better to formally deprecate RFC7050 and focus on other ways to discover the translation prefix. It seems that at least one already exists (RFC7225) so not much is lost. From nobody Wed Jun 13 03:45: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 253B5130E25; Wed, 13 Jun 2018 03:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJCXLe7awNNh; Wed, 13 Jun 2018 03:45:45 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC93130E20; Wed, 13 Jun 2018 03:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528886743; x=1529491543; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Bml4ou0FFQdc/9tV383up1hL0Wd2FnBhVxpBJfUADNY=; b=O8HoXB5sK2bE+ iNqkhgpangsVO3AmTf8QmME/4Q2gm9fezPoBabnaLn3qKEE9gpQo4JHqSJf8YYRy CK9j6Noeob9GpFRnqYARXlcMoyYO4Fz0vPQn5u5ngfkJIJjgLEgmXGknlmiTTwdb GxRgfEDjN2ELrSrDxhuyWH5aY9YL/w= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 12:45:43 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 12:45:42 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788682.msg; Wed, 13 Jun 2018 12:45:41 +0200 X-MDRemoteIP: 2001:470:1f09:495:b9c7:adad:b8cb:35fd X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 12:45:41 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 12:45:38 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , CC: Stuart Cheshire , Michelle Cotton via RT , dnsop , David Schinazi Message-ID: <0076D883-6824-4237-A0B7-8485A3756BB1@consulintel.es> Thread-Topic: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure. References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [DNSOP] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 10:45:49 -0000 Hi Philip, Agree, ideally, should be a DHCPv6 bases mechanism as we already proposed l= ong time ago, because PCP is not present in many networks (unfortunately), = while DHCP is quite common. We are happy to resurrect and review this work if needed: https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: DNSOP en nombre de Philip Homburg Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 12:42 Para: CC: Stuart Cheshire , Michelle Cotton via RT , dnsop , David Schinazi Asunto: Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation shoul= d be insecure. >https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa=20 > =20 >From Section 6.2: 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as special and MUST give it special treatment. Regardless of an= y manual client DNS configuration, DNS overrides configured by VPN client software, or any other mechanisms that influence the choice of the client's recursive resolver address(es) (including client devices that run their own local recursive resolver and use the loopback address as their configured recursive resolver address) all queries for 'ipv4only.arpa' and any subdomains of that name MUST be sent to the recursive resolver learned from th= e network via IPv6 Router Advertisement Options for DNS Configuration [RFC6106] or via DNS Configuration options for DHCPv6 [RFC3646]. =20 First we introduce ipv4only.arpa as a hack to avoid creating/deploying = a suitable mechanism to communicate the NAT64 translation prefix. That's = fine with me. =20 But when that hack then requires changes to every possible DNS stub res= olver implementation in the world, there is something seriously wrong. =20 So if this in indeeed required to make RFC7050 work then it is better t= o formally deprecate RFC7050 and focus on other ways to discover the translation prefix. =20 It seems that at least one already exists (RFC7225) so not much is lost= . =20 =20 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 13 03:55: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 2337F130EC6 for ; Wed, 13 Jun 2018 03:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 DG_KEgDxW0aA for ; Wed, 13 Jun 2018 03:55:42 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA725120049 for ; Wed, 13 Jun 2018 03:55:41 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id v13-v6so2229774wrp.13 for ; Wed, 13 Jun 2018 03:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2YHOw/nwbovsK/DIVqyfuwMX+ulkFlXrMQ9uNBrV1h8=; b=Aeyr4FH8QbQuTqfkAcbsuXqkpmt9LkMB/mYOt1g4+3j1yRmLDe8VTq50VN5fsm24th Stu53tKIRdUbZoQ129vgkk3WAQx83IkiYFtAp/FEQxVXINI/mDMuGLlskzAaiGD5wWjt KHaTgur8JRGXYluM+u4fz2LorjtohtW5eywx1LJkB/3QjUdtUUqvqyG04OwrsGPQL6Kj AYWraMnBxKA+K25Zhj8IHdpEYXmOoaqiaOY8ADZ2mBa5L3CZKHl3tfCRWsLIExV2NhKL vp9x3VeHmZT/mT7AB7O/MOVGK7Uv0tOwTUDxrCMxqj32x80bV0LUP++OE64TiRH7ARPb csQQ== 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=2YHOw/nwbovsK/DIVqyfuwMX+ulkFlXrMQ9uNBrV1h8=; b=K9hTxk9Kmt61OhK0anV+pEtC9sldGVaXywM8LXH+4MVXa3xJycdwwOE5kA/eL77xNc pyU8OPXXLrxwhW2Jkn/hDTSYkcbzPZhL8j9QSuGDiVqei776UEy5v3Hg6nudVggcf06J 32oLPxs7EoVFi0kPxhSIEcUjzzsAeXry7q842sbmQr4a7XdCQtF5Zz6j4oBePGVxYUbB I1kR5J7qybofdZf5WF7Bm8KNHgnhVTVh8mOuk+ICRjA5XKymDILJGapq0miG3/XuimNU WkpIfg3Brx5BG1SU7zaGezJkL4LOVKbIJmoSA7/l4dUSl17NE+0wja4LciOb6haXwwd0 LC0A== X-Gm-Message-State: APt69E1msqrv1eFWWSSAr9C6A6NBSyvIMixLaXnMkCjYmYjOWXUFRRhI 9DHcb0NPNpd326d36lafDmHcKds8b1wmNIo+tlnADdkX X-Google-Smtp-Source: ADUXVKIMytpH5okKuzixMNUnfEJnILBC4xk+S1Y9zUSAOiisNl8xBZIrPrrYzVUcB6Bnoy3BQjyZdrcq5zTjoD9+AUc= X-Received: by 2002:adf:d08b:: with SMTP id y11-v6mr3864439wrh.152.1528887339933; Wed, 13 Jun 2018 03:55:39 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: From: Lorenzo Colitti Date: Wed, 13 Jun 2018 19:55:25 +0900 Message-ID: To: lencse@hit.bme.hu Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000ccf958056e83d2c2" Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 10:55:47 -0000 --000000000000ccf958056e83d2c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here are a few disadvantages of 464xlat: - It consumes lots of state on the NAT64 (one state table entry for every connection). MAP is much better since it uses port ranges. - It doesn't allow any inbound connections unless the NAT cooperates. MAP is better in the sense that you can at least receive connections wit= hin your port range. - The transformation is lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserve= s the original packet header. On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor wrote= : > Dear Lorenzo, > > I think it is a rather strong statement that "464XLAT is pretty much the > worse of the transition mechanisms from a technical perspective." > > We have listed 26+ IPv6 transition technologies in our workshop paper [1]= , > but there are even more solutions exist. > > Which of them do you mean to be better than 464XLAT? > > What technical points do you consider when stating that 464XLAT is worse > than the others? (E.g. resource consumption, scalability, security, ease = of > implementation, etc.) > > I think it is important for network operators to have a balanced view of > the advantages and disadvantages of the different IPv6 transition > mechanisms, this is why I am asking these questions. > > Best regards, > > G=C3=A1bor Lencse > > > [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies > for Security Analysis", IEICE Communications Society Internet Architectur= e > Workshop, Tokyo, Japan, Aug. 28, 2017, *IEICE Tech. Rep.*, vol. 117, no. > 187, pp. 19-24. Available online: > http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf > > > 6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Colitti =C3=ADrta: > > That goes back to my earlier point of that from a technical perspective > 464xlat is pretty much the worst of the transition mechanisms.. I don't > think we should be recommending running it on wireline at all, let alone > prioritizing it over something else .:-) > > On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > >> Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize= , when an >> ISP supports several transition mechanisms. >> >> >> >> RFC8026 key aspect is priority. If we don=E2=80=99t add an option code f= or >> 464XLAT, then it can=E2=80=99t be managed the same way. >> >> >> Regards, >> >> Jordi >> >> >> >> >> >> >> >> *De: *v6ops en nombre de Lorenzo Colitti >> >> *Fecha: *mi=C3=A9rcoles, 13 de junio de 2018, 4:45 >> *Para: * >> *CC: *"v6ops@ietf.org WG" >> *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in >> draft-ietf-v6ops-transition-ipv4aas >> >> >> >> On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ > 40consulintel..es@dmarc.ietf.org <40consulintel.es@dmarc.ietf.org>> >> wrote: >> >> You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) = to tell >> the CLAT the NAT64 prefix. It also provides additional advantages to the >> operator to control many related aspects (see section 3 of RFC7225). >> >> >> >> 1. If the operator wants to enable 464xlat: they should hand out a >> DNS64 to the CPE. >> >> 2. If the operator wants to disable 464xlat: they should NOT hand >> out a DNS64 to the CPE. >> >> This doesn=E2=80=99t work, because the operator may be using RFC7225 ins= tead of >> RFC7050. You need to try both in that case, and you aren=E2=80=99t provi= ding a >> =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which is wh= at RFC8026 does. >> >> >> >> But it's the same problem again: what's the use case for this DHCPv6 >> option? An operator that's using RFC7225 has an easy way to tell the CPE >> not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is >> already possible today. >> >> >> >> 3. If the operator uses 464xlat, they should not allow the user to >> change the DNS server. >> >> >> >> >> >> Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D th= e customer to avoid changing the >> DNS =E2=80=A6 >> >> >> >> On an operator-managed CPE, you can. On a user-managed CPE, you can't. >> But on such a CPE you probably shouldn't be disabling 464xlat. If the us= er >> wants to use it, it's their CPE, right? >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of >> the individual(s) named above and further non-explicilty authorized >> disclosure, copying, distribution or use of the contents of this >> information, even if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you are not the >> intended recipient be aware that any disclosure, copying, distribution o= r >> use of the contents of this information, even if partially, including >> attached files, is strictly prohibited, will be considered a criminal >> offense, so you must reply to the original sender to inform about this >> communication and delete it. >> >> > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6o= ps > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000ccf958056e83d2c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are a few disadvantages of 464xlat:
  • It co= nsumes lots of state on the NAT64 (one state table entry for every connecti= on). MAP is much better since it uses port ranges.
  • It doesn'= ;t allow any inbound connections unless the NAT cooperates. MAP is better i= n the sense that you can at least receive connections within your port rang= e.
  • The transformation is lossy because there are IPv4 header fields= that cannot be translated. MAP-E is better because the encapsulation prese= rves the original packet header.

On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bo= r <lencse@hit.bme.hu> wrote:=
=20 =20 =20
Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty mu= ch the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

G=C3=A1bor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf


6/13/2018 9:38 AM = keltez=C3=A9ssel, Lorenzo Colitti =C3=ADrta:
That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms.. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-)

Lorenzo, you=E2= =80=99re missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

=C2=A0

RFC8026 key aspec= t is priority. If we don=E2=80=99t add an option code for 464XLAT, then it can=E2=80=99t be managed the same way.


Regards,

Jordi

=C2=A0

=C2=A0

=C2=A0

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.o= rg>
Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45=
Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.or= g>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

=C2=A0<= /p>

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel..es@dmarc.ietf.org> wrote:

You don=E2=80=99t need RFC7050 neither DNS64, you can= use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If the operator wants to disable=C2=A0464xlat: they should NOT hand out = a DNS64 to the CPE.

This doesn=E2=80=99t work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you aren=E2=80=99t providing a =E2=80=9Cpri= ority=E2=80=9D to a possible list of mechanisms, which is what RFC8026 does.

=C2= =A0

But it's the same problem again: what's the use c= ase for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

=C2= =A0=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If the operator uses 464xlat, they should not allow the user to change the DNS server.

=C2=A0

=C2=A0

Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the customer to avoid c= hanging the DNS =E2=80=A6

=C2= =A0

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE yo= u probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://= www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000ccf958056e83d2c2-- From nobody Wed Jun 13 04:12: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 F27F8120049 for ; Wed, 13 Jun 2018 04:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVVovdCZHJ5a for ; Wed, 13 Jun 2018 04:12:42 -0700 (PDT) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5B01292F1 for ; Wed, 13 Jun 2018 04:12:42 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5DBCcGl026574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 13 Jun 2018 07:12:38 -0400 Received: (qmail 4208 invoked by uid 0); 13 Jun 2018 11:12:38 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 13 Jun 2018 11:12:38 -0000 To: v6ops@ietf.org References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> From: Lee Howard Message-ID: <63dd2434-bf75-1abd-bb57-53f4be856075@asgard.org> Date: Wed, 13 Jun 2018 07:12:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B18A1461EC6314CED87BB993" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 11:12:45 -0000 This is a multi-part message in MIME format. --------------B18A1461EC6314CED87BB993 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit So you mean "stateful < stateless"? I haven't looked recently at which packet headers get munged in what ways. Care to save us all half an hour of examining RFCs and tell us which ones? Lee On 06/13/2018 06:55 AM, Lorenzo Colitti wrote: > Here are a few disadvantages of 464xlat: > > * It consumes lots of state on the NAT64 (one state table entry for > every connection). MAP is much better since it uses port ranges. > * It doesn't allow any inbound connections unless the NAT > cooperates. MAP is better in the sense that you can at least > receive connections within your port range. > * The transformation is lossy because there are IPv4 header fields > that cannot be translated. MAP-E is better because the > encapsulation preserves the original packet header. > > > On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor > wrote: > > Dear Lorenzo, > > I think it is a rather strong statement that "464XLAT is pretty > much the worse of the transition mechanisms from a technical > perspective." > > We have listed 26+ IPv6 transition technologies in our workshop > paper [1], but there are even more solutions exist. > > Which of them do you mean to be better than 464XLAT? > > What technical points do you consider when stating that 464XLAT is > worse than the others? (E.g. resource consumption, scalability, > security, ease of implementation, etc.) > > I think it is important for network operators to have a balanced > view of the advantages and disadvantages of the different IPv6 > transition mechanisms, this is why I am asking these questions. > > Best regards, > > Gábor Lencse > > > [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition > Technologies for Security Analysis", IEICE Communications Society > Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, > /IEICE Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available > online: > http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf > > > > 6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta: >> That goes back to my earlier point of that from a technical >> perspective 464xlat is pretty much the worst of the transition >> mechanisms.. I don't think we should be recommending running it >> on wireline at all, let alone prioritizing it over something else >> .:-) >> >> On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ >> > > wrote: >> >> Lorenzo, you’re missing the key aspect: Being able to >> prioritize, when an ISP supports several transition mechanisms. >> >> RFC8026 key aspect is priority. If we don’t add an option >> code for 464XLAT, then it can’t be managed the same way. >> >> >> Regards, >> >> Jordi >> >> *De: *v6ops > > en nombre de Lorenzo Colitti >> > > >> *Fecha: *miércoles, 13 de junio de 2018, 4:45 >> *Para: *> > >> *CC: *"v6ops@ietf.org WG" >> > >> *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in >> draft-ietf-v6ops-transition-ipv4aas >> >> On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ >> > > wrote: >> >> You don’t need RFC7050 neither DNS64, you can use PCP >> (RFC7225) to tell the CLAT the NAT64 prefix. It also >> provides additional advantages to the operator to control >> many related aspects (see section 3 of RFC7225). >> >> 1.If the operator wants to enable 464xlat: they should >> hand out a DNS64 to the CPE. >> >> 2.If the operator wants to disable 464xlat: they should >> NOT hand out a DNS64 to the CPE. >> >> This doesn’t work, because the operator may be using >> RFC7225 instead of RFC7050. You need to try both in that >> case, and you aren’t providing a “priority” to a possible >> list of mechanisms, which is what RFC8026 does. >> >> But it's the same problem again: what's the use case for this >> DHCPv6 option? An operator that's using RFC7225 has an easy >> way to tell the CPE not to do 464xlat: don't hand out the >> prefix64 to those CPEs. So this is already possible today. >> >> 3.If the operator uses 464xlat, they should not allow the >> user to change the DNS server. >> >> Let’s be realistic. You can’t “force” the customer to >> avoid changing the DNS … >> >> On an operator-managed CPE, you can. On a user-managed CPE, >> you can't. But on such a CPE you probably shouldn't be >> disabling 464xlat. If the user wants to use it, it's their >> CPE, right? >> >> _______________________________________________ v6ops mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be >> for the exclusive use of the individual(s) named above and >> further non-explicilty authorized disclosure, copying, >> distribution or use of the contents of this information, even >> if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you >> are not the intended recipient be aware that any disclosure, >> copying, distribution or use of the contents of this >> information, even if partially, including attached files, is >> strictly prohibited, will be considered a criminal offense, >> so you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------B18A1461EC6314CED87BB993 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

So you mean "stateful < stateless"?

I haven't looked recently at which packet headers get munged in what ways. Care to save us all half an hour of examining RFCs and tell us which ones?


Lee


On 06/13/2018 06:55 AM, Lorenzo Colitti wrote:
Here are a few disadvantages of 464xlat:
  • It consumes lots of state on the NAT64 (one state table entry for every connection). MAP is much better since it uses port ranges.
  • It doesn't allow any inbound connections unless the NAT cooperates. MAP is better in the sense that you can at least receive connections within your port range.
  • The transformation is lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserves the original packet header.

On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <lencse@hit.bme.hu> wrote:
Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf


6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta:
That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms.. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

Lorenzo, you’re missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

 

RFC8026 key aspect is priority. If we don’t add an option code for 464XLAT, then it can’t be managed the same way.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Fecha: miércoles, 13 de junio de 2018, 4:45
Para: <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel..es@dmarc.ietf.org> wrote:

You don’t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

 

1.       If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.       If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn’t work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you aren’t providing a “priority” to a possible list of mechanisms, which is what RFC8026 does.

 

But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

  

3.       If the operator uses 464xlat, they should not allow the user to change the DNS server.

 

 

Let’s be realistic. You can’t “force” the customer to avoid changing the DNS …

 

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



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

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


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

--------------B18A1461EC6314CED87BB993-- From nobody Wed Jun 13 05:10: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 00A9312F1A5 for ; Wed, 13 Jun 2018 05:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP9ThdbB5Ekq for ; Wed, 13 Jun 2018 05:10:01 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCBF130DEF for ; Wed, 13 Jun 2018 05:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528891797; x=1529496597; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=x+iRO+NBZxFbInhJJX4o42 jLeVKSfLzXe9ryoDAwYqY=; b=Hm0kHz9lrlXX+ocGx6IU3r+TLZGV9fLlxIxXlA HdWur1Zo2f0NfSHf9p1WyCDyuV7fQ4paedsMiz/yurSf+fNgZtGDVmLApDL4r5o3 dohSh7j45a1pYxVGh/Dw8Kb5VILMDAfh+NMeiSP25FMSFqTTZ7zEDCxiWd0MKyzH ZrK7E= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:09:57 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:09:55 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788743.msg for ; Wed, 13 Jun 2018 14:09:52 +0200 X-MDRemoteIP: 2001:470:1f09:495:c981:3ff8:ebcd:b22f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 14:09:52 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 14:09:50 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti , CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611743790_1727464455" Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:10:12 -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_3611743790_1727464455 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable This always depends on your perspective, network, user requirements, etc. D= ifferent operators have different requirements. =20 Here are a few disadvantages of 464xlat: =C2=B7 It consumes lots of state on the NAT64 (one state table entr= y for every connection). MAP is much better since it uses port ranges. Some ISPs care less about state and care more about having a better usage o= f each IPv4 address and providing as many ports as the users need automatic= ally. With NAT64, you have for each user as many ports as they need, nothing =E2= =80=9Cextra=E2=80=9D to configure for each user. With MAP you pre-define a = number of ports per user. =C2=B7 It doesn't allow any inbound connections unless the NAT coop= erates. MAP is better in the sense that you can at least receive connection= s within your port range. Some ISPs don=E2=80=99t want inbound connections to be statically managed b= y users, they offer different services with different prices, etc. I=E2=80= =99m not saying I agree with that. Even do, you have ways to cooperate with= the NAT64, PCP, etc., to do that. Even for corporate users you can mix tha= t with SIIT-DC or alike functions. Inbound connections in your port range is useless for most of the users, or= apps or devices, because they don=E2=80=99t allow other ports, and yes, yo= u can sometimes play tricks with the CPE port forwarding, etc., etc. =C2=B7 The transformation is lossy because there are IPv4 header fi= elds that cannot be translated. MAP-E is better because the encapsulation p= reserves the original packet header. None of the transition mechanisms can be perfect, except probably dual-stac= k, but we know we can=E2=80=99t do dual-stack for every possible network, b= ecause we don=E2=80=99t have sufficient addresses, right? Now, this has been said many times, and I don=E2=80=99t necessarily agree i= nitially, but I=E2=80=99ve started to change my mind in the last few years.= ***We DON=E2=80=99T WANT a perfect transition mechanism.*** We want some apps to fail, so indirectly it forces to developers and conten= t providers to move them to IPv6. So, all them are imperfect in one way or another, but having a single one, = is much better, from all the perspectives that having many. Developers will= fix easier anything for a single mechanism than for many, everything will = happen faster, and of course, since 464XLAT is the one with has more users = worldwide, it makes sense to push for that one everywhere, because the prob= lems that the app developers find in the cellular world, will be sorted out= , so those apps will be fixed for both, cellular and non-cellular. Also, an operator with both, cellular and non-cellular networks, is very in= terested to support a single mechanism instead of two or more. Even an oper= ator without a cellular network, many times need to provide backup by means= of LTE and that means hybrid routers with both wired and LTE interfaces. I= t is much simpler to have a single mechanism for both, because even the cel= lular network is not its own network, it can use the same NAT64 (or the sam= e outsourced one for both kind of connections). I was not a fan of 464XLAT initially when it was developed, but market make= me change my mind. In summary, it all depends on your perspective, but if our goal is to push = as much as possible for a higher % of IPv6-only traffic, I=E2=80=99m convin= ced cellular networks, which are the ones with higher % of penetration and = growth, clearly defined the path that we must follow.=20 =20 On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor wrote= : Dear Lorenzo, I think it is a rather strong statement that "464XLAT is pretty much the wo= rse of the transition mechanisms from a technical perspective." We have listed 26+ IPv6 transition technologies in our workshop paper [1], = but there are even more solutions exist.=20 Which of them do you mean to be better than 464XLAT? What technical points do you consider when stating that 464XLAT is worse th= an the others? (E.g. resource consumption, scalability, security, ease of i= mplementation, etc.) I think it is important for network operators to have a balanced view of th= e advantages and disadvantages of the different IPv6 transition mechanisms,= this is why I am asking these questions. Best regards, G=C3=A1bor Lencse [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies f= or Security Analysis", IEICE Communications Society Internet Architecture W= orkshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, = pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEI= CE-IA-2017-survey.pdf 6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Colitti =C3=ADrta: That goes back to my earlier point of that from a technical perspective 464= xlat is pretty much the worst of the transition mechanisms.. I don't think = we should be recommending running it on wireline at all, let alone prioriti= zing it over something else .:-) =20 On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ wrote: Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize, w= hen an ISP supports several transition mechanisms. =20 RFC8026 key aspect is priority. If we don=E2=80=99t add an option code for = 464XLAT, then it can=E2=80=99t be managed the same way. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ wrote: You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225). =20 1. If the operator wants to enable 464xlat: they should hand out a DN= S64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does. =20 But it's the same problem again: what's the use case for this DHCPv6 option= ? An operator that's using RFC7225 has an easy way to tell the CPE not to d= o 464xlat: don't hand out the prefix64 to those CPEs. So this is already po= ssible today. =20 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. =20 =20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6 =20 On an operator-managed CPE, you can. On a user-managed CPE, you can't. But = on such a CPE you probably shouldn't be disabling 464xlat. If the user want= s to use it, it's their CPE, right? _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ 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 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611743790_1727464455 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

This always depends on = your perspective, network, user requirements, etc. Different operators have= different requirements.

 

Here are a few disadvantages of 464xlat:

=C2=B7         = It consumes lots of state on the NAT64 (one = state table entry for every connection). MAP is much better since it uses p= ort ranges.

Some ISPs care less abo= ut state and care more about having a better usage of each IPv4 address and= providing as many ports as the users need automatically.=

With NAT64, you have for each user as many po= rts as they need, nothing =E2=80=9Cextra=E2=80=9D to configure for each use= r. With MAP you pre-define a number of ports per user.

=C2=B7MAP is better in the sense that you can at least = receive connections within your port range.

Some ISPs don=E2=80=99t want inbound connections to be statically = managed by users, they offer different services with different prices, etc.= I=E2=80=99m not saying I agree with that. Even do, you have ways to cooper= ate with the NAT64, PCP, etc., to do that. Even for corporate users you can= mix that with SIIT-DC or alike functions.

Inbound connections in your port range is useless for most o= f the users, or apps or devices, because they don=E2=80=99t allow other por= ts, and yes, you can sometimes play tricks with the CPE port forwarding, et= c., etc.

=C2=B7       &n= bsp; The transformation i= s lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserves the original packet= header.

None of the transition mec= hanisms can be perfect, except probably dual-stack, but we know we can=E2= =80=99t do dual-stack for every possible network, because we don=E2=80=99t = have sufficient addresses, right?

Now, this has been said many times, and I don=E2=80=99t necessarily a= gree initially, but I=E2=80=99ve started to change my mind in the last few = years. ***We DON=E2=80=99T WANT a perfect transition mechanism.***

We want some apps to f= ail, so indirectly it forces to developers and content providers to move th= em to IPv6.

So, all them are= imperfect in one way or another, but having a single one, is much better, = from all the perspectives that having many. Developers will fix easier anyt= hing for a single mechanism than for many, everything will happen faster, a= nd of course, since 464XLAT is the one with has more users worldwide, it ma= kes sense to push for that one everywhere, because the problems that the ap= p developers find in the cellular world, will be sorted out, so those apps = will be fixed for both, cellular and non-cellular.

Also, an operator with both, cellular and non-cellul= ar networks, is very interested to support a single mechanism instead of tw= o or more. Even an operator without a cellular network, many times need to = provide backup by means of LTE and that means hybrid routers with both wire= d and LTE interfaces. It is much simpler to have a single mechanism for bot= h, because even the cellular network is not its own network, it can use the= same NAT64 (or the same outsourced one for both kind of connections).=

I was not a fan of 464XLAT initi= ally when it was developed, but market make me change my mind.

In summary, it all depends on your persp= ective, but if our goal is to push as much as possible for a higher % of IP= v6-only traffic, I=E2=80=99m convinced cellular networks, which are the one= s with higher % of penetration and growth, clearly defined the path that we= must follow.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>On Wed, Jun 13, 2018 at 6:= 12 PM Lencse G=C3=A1bor <lencse@hit= .bme.hu> wrote:

Dear Lorenzo,<= br>
I think it is a rather strong statement that "464XLAT is pretty= much the worse of the transition mechanisms from a technical perspective.&= quot;

We have listed 26+ IPv6 transition technologies in our worksho= p paper [1], but there are even more solutions exist.

Which of them= do you mean to be better than 464XLAT?

What technical points do you= consider when stating that 464XLAT is worse than the others? (E.g. resourc= e consumption, scalability, security, ease of implementation, etc.)

= I think it is important for network operators to have a balanced view of th= e advantages and disadvantages of the different IPv6 transition mechanisms,= this is why I am asking these questions.

Best regards,

G=C3= =A1bor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of = IPv6 Transition Technologies for Security Analysis", IEICE Communicati= ons Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017= -survey.pdf

6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Colitti =C3= =ADrta:

That goe= s back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanism= s.. I don't think we should be recommending running it on wireline at all, = let alone prioritizing it over something else .:-)

 

On Wed, Jun 13, 2018 at= 3:50 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

Lorenzo, = you=E2=80=99re missing the key aspect: Being able to prioritize, when an IS= P supports several transition mechanisms.

 

RFC8026 key aspect is priority. If we don=E2= =80=99t add an option code for 464XLAT, then it can=E2=80=99t be managed th= e same way.


Regards,

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;m= argin-left:35.4pt'>Jordi

 

 

 

De: v6ops = <v6ops-bounc= es@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.iet= f.org>
Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC:= "v6ops@ietf.o= rg WG" <v6o= ps@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to suppo= rt 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

=

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTI= NEZ <jordi.palet=3D40consulintel..es@dmarc.ietf.org> wrote:<= /p>

You don=E2=80=99= t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT th= e NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RF= C7225).

 

1. &= nbsp;     If the operator wants to enable 464xlat: they= should hand out a DNS64 to the CPE.

2.       If the = operator wants to disable 464xlat: they should NOT hand out a DNS64 to= the CPE.

This doesn=E2=80=99t work, because the operator may be using RFC7225 inste= ad of RFC7050. You need to try both in that case, and you aren=E2=80=99t pr= oviding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, whic= h is what RFC8026 does.

=

 

But it's the same problem again: what's the use case for this DHCP= v6 option? An operator that's using RFC7225 has an easy way to tell the CPE= not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is a= lready possible today.

=   

3.       If the o= perator uses 464xlat, they should not allow the user to change the DNS serv= er.

 = ;

 <= /span>

Let=E2=80= =99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the customer t= o avoid changing the DNS =E2=80=A6

 

On an operator-managed CPE, you can. On a user-managed = CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xl= at. If the user wants to use it, it's their CPE, right?

____________________________________= ___________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= o:p>


***************= *******************************
IPv4 is over
Are you ready for the ne= w Internet ?
htt= p://www.consulintel.es
The IPv6 Company

This electronic messa= ge contains information which may be privileged or confidential. The inform= ation is intended to be for the exclusive use of the individual(s) named ab= ove and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this info= rmation, even if partially, including attached files, is strictly prohibite= d and will be considered a criminal offense. If you are not the intended re= cipient be aware that any disclosure, copying, distribution or use of the c= ontents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must r= eply to the original sender to inform about this communication and delete i= t.



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

 

_______________________________= ________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611743790_1727464455-- From nobody Wed Jun 13 05:21: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 9A74E130DEF for ; Wed, 13 Jun 2018 05:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNVoGLCJjjyi for ; Wed, 13 Jun 2018 05:21:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC701294D7 for ; Wed, 13 Jun 2018 05:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528892485; x=1529497285; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=ZBok1YxVqDmMvY8QRBlpnd +DQbDz+wmUEFfxtRJ1MRA=; b=F+agpjvupJqiylNBPPzgVbJpwKe6ciEPTm9qiB nHWOPqP/wjG+9/SlzonkSv9xEW0dcdAQgo4YKBNcpxM63Wp1MedL+iVP3YyMP1aS R4YfrBwA9COmHF0ZUVAtoiTUAgHFw+4dMuelesJ3nK/LYKiOqiTot4nZ7OBWjH6y El754= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:21:25 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:21:24 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788752.msg for ; Wed, 13 Jun 2018 14:21:22 +0200 X-MDRemoteIP: 2001:470:1f09:495:c981:3ff8:ebcd:b22f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 14:21:22 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 14:21:17 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti , CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611744478_1151862628" Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:21:34 -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_3611744478_1151862628 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Resending as my email client formatted it weirdly =E2=80=A6 and adding one = more comment. =20 This always depends on your perspective, network, user requirements, etc. D= ifferent operators have different requirements. =20 Here are a few disadvantages of 464xlat: =C2=B7 It consumes lots of state on the NAT64 (one state table entr= y for every connection). MAP is much better since it uses port ranges. =20 Some ISPs care less about state and care more about having a better usage o= f each IPv4 address and providing as many ports as the users need automatic= ally. =20 With NAT64, you have for each user as many ports as they need, nothing =E2= =80=9Cextra=E2=80=9D to configure for each user. With MAP you pre-define a = number of ports per user. =20 Consequently, with NAT64 you make a much better usage of every single IPv4 = address, because they become shared based dynamically on =E2=80=9Creal-flow= -per-port=E2=80=9D needs at each given time. =20 =20 =C2=B7 It doesn't allow any inbound connections unless the NAT coop= erates. MAP is better in the sense that you can at least receive connection= s within your port range. =20 Some ISPs don=E2=80=99t want inbound connections to be statically managed b= y users, they offer different services with different prices, etc. I=E2=80= =99m not saying I agree with that. Even do, you have ways to cooperate with= the NAT64, PCP, etc., to do that. Even for corporate users you can mix tha= t with SIIT-DC or alike functions. =20 Inbound connections in your port range is useless for most of the users, or= apps or devices, because they don=E2=80=99t allow other ports, and yes, yo= u can sometimes play tricks with the CPE port forwarding, etc., etc. =C2=B7 The transformation is lossy because there are IPv4 header fi= elds that cannot be translated. MAP-E is better because the encapsulation p= reserves the original packet header. =20 None of the transition mechanisms can be perfect, except probably dual-stac= k, but we know we can=E2=80=99t do dual-stack for every possible network, b= ecause we don=E2=80=99t have sufficient addresses, right? =20 Now, this has been said many times, and I don=E2=80=99t necessarily agree i= nitially, but I=E2=80=99ve started to change my mind in the last few years.= ***We DON=E2=80=99T WANT a perfect transition mechanism.*** =20 We want some apps to fail, so indirectly it forces to developers and conten= t providers to move them to IPv6. =20 So, all them are imperfect in one way or another, but having a single one, = is much better, cheaper and easier, from all the perspectives that having m= any. Developers will fix easier anything for a single mechanism than for ma= ny, everything will happen faster, and of course, since 464XLAT is the one = with has more users worldwide, it makes sense to push for that one everywhe= re, because the problems that the app developers find in the cellular world= , will be sorted out, so those apps will be fixed for both, cellular and no= n-cellular. =20 Also, an operator with both, cellular and non-cellular networks, is very in= terested to support a single mechanism instead of two or more. Even an oper= ator without a cellular network, many times need to provide backup by means= of LTE and that means hybrid routers with both wired and LTE interfaces. I= t is much simpler to have a single mechanism for both, because even the cel= lular network is not its own network, it can use the same NAT64 (or the sam= e outsourced one for both kind of connections). =20 I was not a fan of 464XLAT initially when it was developed, but market make= me change my mind. =20 In summary, it all depends on your perspective, but if our goal is to push = as much as possible for a higher % of IPv6-only traffic, I=E2=80=99m convin= ced cellular networks, which are the ones with higher % of penetration and = growth, clearly defined the path that we must follow.=20 =20 =20 On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor wrote= : Dear Lorenzo, I think it is a rather strong statement that "464XLAT is pretty much the wo= rse of the transition mechanisms from a technical perspective." We have listed 26+ IPv6 transition technologies in our workshop paper [1], = but there are even more solutions exist.=20 Which of them do you mean to be better than 464XLAT? What technical points do you consider when stating that 464XLAT is worse th= an the others? (E.g. resource consumption, scalability, security, ease of i= mplementation, etc.) I think it is important for network operators to have a balanced view of th= e advantages and disadvantages of the different IPv6 transition mechanisms,= this is why I am asking these questions. Best regards, G=C3=A1bor Lencse [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies f= or Security Analysis", IEICE Communications Society Internet Architecture W= orkshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, = pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEI= CE-IA-2017-survey.pdf 6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Colitti =C3=ADrta: That goes back to my earlier point of that from a technical perspective 464= xlat is pretty much the worst of the transition mechanisms.. I don't think = we should be recommending running it on wireline at all, let alone prioriti= zing it over something else .:-) =20 On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ wrote: Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize, w= hen an ISP supports several transition mechanisms. =20 RFC8026 key aspect is priority. If we don=E2=80=99t add an option code for = 464XLAT, then it can=E2=80=99t be managed the same way. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lorenzo Colitti Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45 Para: CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas =20 On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ wrote: You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225). =20 1. If the operator wants to enable 464xlat: they should hand out a DN= S64 to the CPE. 2. If the operator wants to disable 464xlat: they should NOT hand out= a DNS64 to the CPE. This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does. =20 But it's the same problem again: what's the use case for this DHCPv6 option= ? An operator that's using RFC7225 has an easy way to tell the CPE not to d= o 464xlat: don't hand out the prefix64 to those CPEs. So this is already po= ssible today. =20 3. If the operator uses 464xlat, they should not allow the user to ch= ange the DNS server. =20 =20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6 =20 On an operator-managed CPE, you can. On a user-managed CPE, you can't. But = on such a CPE you probably shouldn't be disabling 464xlat. If the user want= s to use it, it's their CPE, right? _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =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 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611744478_1151862628 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Resending as my email c= lient formatted it weirdly =E2=80=A6 and adding one more comment.

 

This always depends on your pe= rspective, network, user requirements, etc. Different operators have differ= ent requirements.

 

Here are a few disadvantages of 464xlat:

=C2=B7         = It consumes lots of state on the= NAT64 (one state table entry for every connection). MAP is much bet= ter since it uses port ranges.

 

Some ISPs care less about state and = care more about having a better usage of each IPv4 address and providing as= many ports as the users need automatically.

<= span lang=3DEN-US> 

Wit= h NAT64, you have for each user as many ports as they need, nothing =E2=80= =9Cextra=E2=80=9D to configure for each user. With MAP you pre-define a num= ber of ports per user.

=  

Consequently, with NAT64 y= ou make a much better usage of every single IPv4 address, because they beco= me shared based dynamically on =E2=80=9Creal-flow-per-port=E2=80=9D needs a= t each given time.

&nbs= p;

 

=C2=B7         = It doesn't allow any inbound connection= s unless the NAT cooperates. MAP is better in the sense that you can at lea= st receive connections within your port range.

=  

= Some ISPs don=E2=80=99t want inbound connections to be statically managed b= y users, they offer different services with different prices, etc. I=E2=80= =99m not saying I agree with that. Even do, you have ways to cooperate with= the NAT64, PCP, etc., to do that. Even for corporate users you can mix tha= t with SIIT-DC or alike functions.

 

Inbound conn= ections in your port range is useless for most of the users, or apps or dev= ices, because they don=E2=80=99t allow other ports, and yes, you can sometim= es play tricks with the CPE port forwarding, etc., etc.

=C2=B7         The transformation is lossy because= there are IPv4 header fields that cannot be translated. MAP-E is better be= cause the encapsulation preserves the original packet header.

 

None of the transition mechanisms can be perfect, except proba= bly dual-stack, but we know we can=E2=80=99t do dual-stack for every possib= le network, because we don=E2=80=99t have sufficient addresses, right?=

 

Now, this has been said many times, and I don=E2=80= =99t necessarily agree initially, but I=E2=80=99ve started to change my min= d in the last few years. ***We DON=E2=80=99T WANT a perfect transition mech= anism.***

 <= /span>

We want some apps to fail, so indirectl= y it forces to developers and content providers to move them to IPv6.<= /o:p>

 

So, all them are imperfect in one way or another, but = having a single one, is much better, cheaper and easier, from all the persp= ectives that having many. Developers will fix easier anything for a single = mechanism than for many, everything will happen faster, and of course, sinc= e 464XLAT is the one with has more users worldwide, it makes sense to push = for that one everywhere, because the problems that the app developers find = in the cellular world, will be sorted out, so those apps will be fixed for = both, cellular and non-cellular.

 

Also, an operato= r with both, cellular and non-cellular networks, is very interested to supp= ort a single mechanism instead of two or more. Even an operator without a c= ellular network, many times need to provide backup by means of LTE and that= means hybrid routers with both wired and LTE interfaces. It is much simple= r to have a single mechanism for both, because even the cellular network is= not its own network, it can use the same NAT64 (or the same outsourced one= for both kind of connections).

 

I was not a fan o= f 464XLAT initially when it was developed, but market make me change my min= d.

 <= /p>

In summary, it all depends on your perspective= , but if our goal is to push as much as possible for a higher % of IPv6-only traffic, I=E2=80=99m convince= d cellular networks, which are the ones with higher % of penetration and gr= owth, clearly defined the path that we must follow.

<= /div>

 

&nb= sp;

On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor &= lt;lencse@hi= t.bme.hu> wrote:

Dear Lorenzo,

I think it is a rather strong statement that "46= 4XLAT is pretty much the worse of the transition mechanisms from a technica= l perspective."

We have listed 26+ IPv6 transition technologies= in our workshop paper [1], but there are even more solutions exist.
Which of them do you mean to be better than 464XLAT?

What technica= l points do you consider when stating that 464XLAT is worse than the others= ? (E.g. resource consumption, scalability, security, ease of implementation= , etc.)

I think it is important for network operators to have a bala= nced view of the advantages and disadvantages of the different IPv6 transit= ion mechanisms, this is why I am asking these questions.

Best regard= s,

G=C3=A1bor Lencse


[1] G. Lencse and Y. Kadobayashi, &q= uot;Survey of IPv6 Transition Technologies for Security Analysis", IEI= CE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug= . 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Availabl= e online: http://www.hit.b= me.hu/~lencse/publications/IEICE-IA-2017-survey.pdf

6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Coli= tti =C3=ADrta:

That goes back to my earlier point of that from a = technical perspective 464xlat is pretty much the worst of the transition me= chanisms.. I don't think we should be recommending running it on wireline a= t all, let alone prioritizing it over something else .:-)=

 

On Wed, Jun 13, 2018 at 3:50 PM JORDI P= ALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.= ietf.org> wrote:

Lore= nzo, you=E2=80=99re missing the key aspect: Being able to prioritize, when = an ISP supports several transition mechanisms.

 

RFC8026 key aspect is priority. If we = don=E2=80=99t add an option code for 464XLAT, then it can=E2=80=99t be mana= ged the same way.


Regards,

Jordi

&n= bsp;

 

 

= De: v6= ops <v6ops-bounc= es@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org&= gt;
Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45
Para: = <jordi.palet=3D<= a href=3D"mailto:40consulintel.es@dmarc.ietf.org" target=3D"_blank">40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org<= span lang=3DEN-US style=3D'font-size:12.0pt;color:black'> WG" <v6ops@ietf.org>
Asunt= o: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-= transition-ipv4aas

 

=

On Tue, J= un 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel..es@dmarc.ietf.org>= wrote:

You don=E2=80=99t need RFC7050 neither DNS64, = you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provid= es additional advantages to the operator to control many related aspects (s= ee section 3 of RFC7225).

=  

1.       If the operator = wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.  = ;     If the operator wants to disable 464xlat: th= ey should NOT hand out a DNS64 to the CPE.

This doesn=E2=80=99t work, because the op= erator may be using RFC7225 instead of RFC7050. You need to try both in tha= t case, and you aren=E2=80=99t providing a =E2=80=9Cpriority=E2=80=9D to a = possible list of mechanisms, which is what RFC8026 does.<= /p>

 

But it's the same problem again: what's the use case for this D= HCPv6 option? An operator that's using RFC7225 has an easy way to tell the = CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this i= s already possible today.

  

3. &nbs= p;     If the operator uses 464xlat, they should not al= low the user to change the DNS server.

 

 

Let=E2=80=99s be realistic. You can=E2=80=99t =E2= =80=9Cforce=E2=80=9D the customer to avoid changing the DNS =E2=80=A6<= /o:p>

 

On an operator-managed CPE, you can. On a user-man= aged CPE, you can't. But on such a CPE you probably shouldn't be disabling = 464xlat. If the user wants to use it, it's their CPE, right?

_____= __________________________________________ v6ops mailing list v6ops@ietf= .org https://www.ietf.org/mailman/listinfo/v6o= ps


******************************= ****************
IPv4 is over
Are you ready for the new Internet ?http://www.consulintel.es
The IPv= 6 Company

This electronic message contains information which may be = privileged or confidential. The information is intended to be for the exclu= sive use of the individual(s) named above and further non-explicilty author= ized disclosure, copying, distribution or use of the contents of this infor= mation, even if partially, including attached files, is strictly prohibited= and will be considered a criminal offense. If you are not the intended rec= ipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partiall= y, including attached files, is strictly prohibited, will be considered a c= riminal offense, so you must reply to the original sender to inform about t= his communication and delete it.

 

__________=
_____________________________________
v6ops mailing list=

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

 

____________= ___________________________________
v6ops mailing list
v6ops@ietf.= org
https://www.i= etf.org/mailman/listinfo/v6ops

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


**********************************************<= br> IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611744478_1151862628-- From nobody Wed Jun 13 05:29: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 5522E130DEF for ; Wed, 13 Jun 2018 05:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPATqJx4MKOL for ; Wed, 13 Jun 2018 05:29:21 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D991294D7 for ; Wed, 13 Jun 2018 05:29:20 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v13-v6so2539714wrp.13 for ; Wed, 13 Jun 2018 05:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=h7j/xsLVCNNjQI7/eEbfTN14yyEtfggM0E/6ZBEsC4E=; b=Y5bFyAPrr/g7F9IL9BQfUF4yy5F8fNz+EfSc6jSTf4tl3zP8xflTgu7yfYPL0I65dP BXAfcgr77iwfQqyEg25Hvn82u0IrvEIPQAIagLHdKCwBA3Ck6l9tzHPVlusiDCZ9WBIW 6VzV49qbZyGL4lP0edbCaxLjMo3UYr+EHnvqtRIfa0wkxpOGTsjjd9H+bGvw4TGqFNh4 0dDNnXqgBuUgb4za3CGPGWx36OFWdzZTDyuphqUHDdwntsOPL6Oa84XHpsR7lKomCXxp 3YA76ZpOSxh542QETwJKPVJXewW7MoPsceWGvXgq44aTZo9EqWs/VktPxMUP/UihyhH+ 2b9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h7j/xsLVCNNjQI7/eEbfTN14yyEtfggM0E/6ZBEsC4E=; b=EGJuU1vkwsbEqtCr/b0mbP3ePC1TenAOeo7wZwzE1SzI+LqXIJexsH7R2HjgDa17Rm yzlkw8W7tRamC0Gfi2O9E5X/oTaqvGHzpgQjA6K4nB3YX8DpAQma7KdLfIjYPCuIKdh+ 1rwGA7h9OYs+kAq5AS5vX4/uqoIuGkmM8EphK55pE5YXWzOXQcY8hZJVWSYlmd2ujidb BXcO11v/SwHu/n8yy4V6mFyX/4lsBWJAuNQdwJdVRpwX1G4nPvYJlM8d3TqgekJNED5y Z8DFTaX9reid7DA6/VRXFONbcEURTUhNU2w8Xf6xoJuNGfKxyEw/fED8Mc4Ap05QEphY PdGA== X-Gm-Message-State: APt69E3jq/XBhuh+30FUOrmMFJbbWDi4kpaF9xerxczY4pyKC/xVktrd S74zonesFcVonlmQCUzNhUYR6g== X-Google-Smtp-Source: ADUXVKJsXUTI4MnBqgdt0CtcC81A2hP0Pb3aIb6MW6bT3GiM0crHuj8s2unvBe9GzBLgUu4UOsjuAw== X-Received: by 2002:adf:c4d0:: with SMTP id o16-v6mr4001366wrf.173.1528892959196; Wed, 13 Jun 2018 05:29:19 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2c:2f:3db9:641:5f8e:385? (2a01cb099f2c002f3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2c:2f:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id c53-v6sm6923635wrg.12.2018.06.13.05.29.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 05:29:18 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: v6ops@ietf.org References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> Message-ID: <0a473a91-b611-ddbd-c678-6df9d1efa898@gmail.com> Date: Wed, 13 Jun 2018 14:29:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:29:27 -0000 Le 13/06/2018 à 11:20, Alexandre Petrescu a écrit : > > > Le 27/04/2018 à 05:12, Jen Linkova a écrit : >> On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu >> wrote: >>> Even us, at IETF, whenever we write a new hot Internet Draft we put it >>> on an IPv4 website first. >> Actually we we don't. >> >>> (I guess datatracker is not reachable on IPv6, >>> just guess.) >> >> I've just completely disabled IPv4 on my workstation and >> https://datatracker.ietf.org works just fine (I tested browsing the >> drafts and some links on WG Chair dashboard). > > I have just used an IPv6 linux laptop on an IPv6 cellular link that > gives no IPv4. > > The laptop connects ok to https://ietf.org, tools.ietf.org.  I have even > tried to register for the next meeting.  I went with the process up to > filling the data, but stopped there. > > There are however some websites that dont work, like github.com.  Many > people use github for IETF work like drafts, charters, etc. Other important thing that does not work on IPv6 is paypal.com. I just tried it and it does not work on IPv6, whereas ietf.org works ok on IPv6. paypal is very important for me during the registration process to participate to IETF. It is very important because I prefer it for security reasons. In the past I had some problems paying with something else than paypal. Now I prefer paypal for whatever I pay. Without paying with paypal I would not register to IETF. (this time I dont come to IETF, so it is not really paramount importance, but just to let you know: somebody that wants to use IPv6 and paypal to come to IETF can not). (this email was sent from a Windows client whose IPv4 box was unchecked, and the cellular network access is of PDP type 'IPv6', and with a smtp server from google). Alex > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jun 13 05:31:01 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 DD2B1130E1C for ; Wed, 13 Jun 2018 05:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkQE9rB42jyi for ; Wed, 13 Jun 2018 05:30:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E81130E0D for ; Wed, 13 Jun 2018 05:30:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fT4vH-0000IOC; Wed, 13 Jun 2018 14:30:47 +0200 Message-Id: To: v6ops@ietf.org Cc: JORDI PALET MARTINEZ From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-reply-to: Your message of "Wed, 13 Jun 2018 14:21:17 +0200 ." Date: Wed, 13 Jun 2018 14:30:46 +0200 Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:30:58 -0000 > Now, this has been said many times, and I don't necessarily > agree initially, but I've started to change my mind in the last > few years. ***We DON'T WANT a perfect transition mechanism.*** > > > We want some apps to fail, so indirectly it forces to developers > and content providers to move them to IPv6. If you want people to dislike IPv6, then this is the way to do it. There are plenty of ISPs that used to provide customers with a native IPv4 address and then migrade to IPv6 with some form of NAT. The way this registers with users is that you don't want IPv6 because that breaks your internet connection. There is already a sentiment that IPv6 doesn't do anything useful. That is now becoming that IPv6 will harm your internet connection. Hang on to your IPv4 address as long as you can. From nobody Wed Jun 13 05:44: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 A3928130E0D for ; Wed, 13 Jun 2018 05:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXHCWMZQP5ap for ; Wed, 13 Jun 2018 05:44:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE119130DDA for ; Wed, 13 Jun 2018 05:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528893864; x=1529498664; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=dIzal0iV bUjzJuYsjbpLluCAc3mnLaOiD1cVr9c7ouU=; b=q66X97gZcohLT0eIjfa6wJIR 3QIOYL3UQO7nQZGx8Ze/AJ4ADep6O7EniIU3fzs/07fGyiS9cAvsV0o7GpWC9k3D mVrfclELPUtwAiLCYF5eHcQTeuEPs8VL3apc7/GnvLtSRunynKiflzcGATIAPrdO ri6/8oWALmjM4mHpaR0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:44:24 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:44:24 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788773.msg for ; Wed, 13 Jun 2018 14:44:22 +0200 X-MDRemoteIP: 2001:470:1f09:495:c981:3ff8:ebcd:b22f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 14:44:22 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 14:44:19 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: Thread-Topic: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:44:30 -0000 > Now, this has been said many times, and I don't necessarily > agree initially, but I've started to change my mind in the last > few years. ***We DON'T WANT a perfect transition mechanism.*** > > > We want some apps to fail, so indirectly it forces to developers > and content providers to move them to IPv6. If you want people to dislike IPv6, then this is the way to do it. Don't read it literally, and also understand that I've said " and I don't necessarily agree initially". What I'm trying to say is that is that if 464XLAT is working in cellular, problems will appear there, users there can't switch off IPv6, so problems get sorted out by the app developer, and that means also sorted out in the wireline. I'm not trying to say "make it imperfect on purpose!" There are plenty of ISPs that used to provide customers with a native IPv4 address and then migrade to IPv6 with some form of NAT. The way this registers with users is that you don't want IPv6 because that breaks your internet connection. There is already a sentiment that IPv6 doesn't do anything useful. That is now becoming that IPv6 will harm your internet connection. Hang on to your IPv4 address as long as you can. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Wed Jun 13 05:47: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 2E971130E13 for ; Wed, 13 Jun 2018 05:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI0WTJcC8q-f for ; Wed, 13 Jun 2018 05:47:38 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385E6130DDA for ; Wed, 13 Jun 2018 05:47:38 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id j15-v6so5212624wme.0 for ; Wed, 13 Jun 2018 05:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=hLG52m1xIa0EZisDNSKDtme5riuwTV5v1vWLcm5F2NI=; b=I0EptYwbXKkC40p+N9iM6tAU5MBTIKHrDcNTOwh8CYvYBdlTDpmDR3W8YEWP+291mB 78++VZU26wsGJ4eJA7fZKlA6BSufPOSBTMgAfJ2fhDENyJIdm1P+2EyWR6Ro5wbNYhHc xTv7PzCvlu27TMpQ04fX4xjsfiKggQON+jErJZ0v9z79qtdD4wiELPwc/esCCjS2WFl2 lqIqsUEpAGfupORAKrAJMa+MCVb2e8K2U6YU/Z0WrCBUSjHmx/RRygvV5OOVFRHIVWv3 SYSTstdPrm9NLG1PFryle+j34Lew4OHEWbP8kY68zEXb4THWwC6AME8SNKNGckOeC57F ViMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hLG52m1xIa0EZisDNSKDtme5riuwTV5v1vWLcm5F2NI=; b=tSKjOKIkHqFR2NGt8BTOdXKJBf9FPXCSfFm2OUXTiQl4mIrfLOeF1sAxZaFw6kEf1f //UbR9LekmMooWG141qauQsyfJ9tciN/+XJ0WF1Zf3oqnnZqJkhZPSESBATE2AvjoJUI 4IqlUEVmxEq19GK0IWTDrq8zT0NG7P1M0xVfY8YFIfeFrjIdU132USEbXSXmnxYS0h1k 3s12dvpZ2cxiT2DTw9hjZITnEhYbUzjKIJkmqxmo5h2psQL6WHRvp46XZsHI87KZUlJT XrH7Rhg1rsqsbPSiZp525ZR/WMrssq8YOz5+fEPge/7qL4IU/pyOVlYPGSalxQOYOVYG HISA== X-Gm-Message-State: APt69E3lgf4lO8cSnE9VXCyFiOwAB39T9iFqvLPTG7ddfcyt/RaWFzSU 2dGqzp0wzCRbP90o5oez8Immtw== X-Google-Smtp-Source: ADUXVKLL46ZwOm5m9BJQ51WOlPzWol5uAN/ckpv8H8V2gg7YV2ipti013QEglTc9BdfyEX9sO7PZFw== X-Received: by 2002:a1c:206:: with SMTP id 6-v6mr3662566wmc.114.1528894056588; Wed, 13 Jun 2018 05:47:36 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2c:2f:3db9:641:5f8e:385? (2a01cb099f2c002f3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2c:2f:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id b80-v6sm4382586wmf.2.2018.06.13.05.47.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 05:47:36 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: v6ops@ietf.org References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> Message-ID: Date: Wed, 13 Jun 2018 14:47:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:47:42 -0000 When going to IETF meetings, one is concerned about which hotel to book. Typically the concerns are the price range, distance from IETF venue, transportation, comfort conditions, WiFi, breakfast, rating by others, etc. One other interesting criterion is whether the reservation with the link provided by IETF can be made on IPv6, or not. For IETF 102 Fairmont the Queen Elizabeth: IPv6 reservation ok Le Centre Sheraton: IPv6 reservation not possible others... Alex Le 13/06/2018 à 11:20, Alexandre Petrescu a écrit : > > > Le 27/04/2018 à 05:12, Jen Linkova a écrit : >> On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu >> wrote: >>> Even us, at IETF, whenever we write a new hot Internet Draft we put it >>> on an IPv4 website first. >> Actually we we don't. >> >>> (I guess datatracker is not reachable on IPv6, >>> just guess.) >> >> I've just completely disabled IPv4 on my workstation and >> https://datatracker.ietf.org works just fine (I tested browsing the >> drafts and some links on WG Chair dashboard). > > I have just used an IPv6 linux laptop on an IPv6 cellular link that > gives no IPv4. > > The laptop connects ok to https://ietf.org, tools.ietf.org.  I have even > tried to register for the next meeting.  I went with the process up to > filling the data, but stopped there. > > There are however some websites that dont work, like github.com.  Many > people use github for IETF work like drafts, charters, etc. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jun 13 05:51: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 8821A130E13 for ; Wed, 13 Jun 2018 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyyNIUe6p8QV for ; Wed, 13 Jun 2018 05:50:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594B4130E1F for ; Wed, 13 Jun 2018 05:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528894254; x=1529499054; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=p1rejGGv FZYw5V0fgxhLWYDYmIxPCwSAGf1Nd1L27sU=; b=nF3SEmIzXGYkYYIccfDu60L0 0QDox9EM7VO2h4OlMJQH9vO9R48/mOYuYGVv+ILwq5Q3E/DdwJkcH/zHyUwd8QNi 7rpS8qqKCaRrWRscPrmBPRpCHka5miqKAThTEVoUAM9v/iI4jVmL6N2caPVsCWdN m1ueVCrNSquhC+ksOF4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:50:54 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 14:50:54 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788778.msg for ; Wed, 13 Jun 2018 14:50:52 +0200 X-MDRemoteIP: 2001:470:1f09:495:c981:3ff8:ebcd:b22f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 14:50:52 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 14:50:48 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , Message-ID: <7B224DDD-B66C-4DB2-AA0D-F8477A052CA9@consulintel.es> Thread-Topic: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:51:03 -0000 In fact ... I started to believe a few years ago, that the worst mistake th= e IETF did with IPv6, was to define more than just one transition mechanism= . Maybe we needed one for 6in4 and one for 4in6, that's it. If we had focused in only one (even if not perfect), since the beginning, a= ll routers will support it, will be the same for wired and not wired networ= ks, we could have saved tons of hours of work to many IETF WGs, many OS and= app developers, many operators, many enterprises, many students, etc. Of course, we didn't knew (no crystal ball) how this will evolve. Maybe is time to start deprecating 6in4 ones and may be some of the 4in6 on= es as well? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 14:45 Para: Philip Homburg , Asunto: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition= technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6o= ps-transition-ipv4aas =20 =20 > Now, this has been said many times, and I don't necessarily =20 > agree initially, but I've started to change my mind in the las= t =20 > few years. ***We DON'T WANT a perfect transition mechanism.**= * =20 >=20 =20 >=20 =20 > We want some apps to fail, so indirectly it forces to develope= rs =20 > and content providers to move them to IPv6. =20 =20 =20 If you want people to dislike IPv6, then this is the way to do it. =20 =20 =20 =20 =20 Don't read it literally, and also understand that I've said " and I don= 't necessarily agree initially". What I'm trying to say is that is that if = 464XLAT is working in cellular, problems will appear there, users there can= 't switch off IPv6, so problems get sorted out by the app developer, and th= at means also sorted out in the wireline. I'm not trying to say "make it im= perfect on purpose!" =20 =20 =20 =20 =20 There are plenty of ISPs that used to provide customers with a nati= ve IPv4 =20 address and then migrade to IPv6 with some form of NAT. =20 =20 =20 The way this registers with users is that you don't want IPv6 becau= se that =20 breaks your internet connection. =20 =20 =20 There is already a sentiment that IPv6 doesn't do anything useful. = That is =20 now becoming that IPv6 will harm your internet connection. Hang on = to your =20 IPv4 address as long as you can. =20 =20 =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 13 05:55: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 EB507130E1F for ; Wed, 13 Jun 2018 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOqBUNrK7I-K for ; Wed, 13 Jun 2018 05:55:39 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26B5126CC7 for ; Wed, 13 Jun 2018 05:55:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id CD199FAC4B1 for ; Wed, 13 Jun 2018 09:55:35 -0300 (ART) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kTDMN5KLshqK for ; Wed, 13 Jun 2018 09:55:33 -0300 (ART) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 6A3A8FAC4F4 for ; Wed, 13 Jun 2018 09:55:33 -0300 (ART) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 6A3A8FAC4F4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=AF3BF44E-65A6-11E7-AE62-64B2068F9D73; t=1528894533; bh=b2h7dFyr1eMClE+4MhR+cMV9e0a6KH1OTPUs+kC9IKE=; h=Date:From:To:Message-ID:MIME-Version; b=so/13zetRNEX207z5rMluqxwfY7jQnnp93QdtNzlXYcuEpCHcXdafCq88EO39QMSV g8JuImmVxFpi1mU5qwXGzXTxoz2gL5k56gV/LdnhgrnQwn4C5vbi14YLaSSLIXzvDI 9C2WSMzlvMj5FY/O+CbBl7Us+Bfl18QY+HyNMooU0TM2KGImMqCVnUqrc6pJnRPHNe Zi7JUYX2Co0/0uIvVTtooNajzaYWMuMnAoDS+5SVx24Df1BAEx3vKDIk60RsvEgfY5 I5RrwnSoxRFBe5T179TKHy2K8R7qTV9T432LdVK+pZv1GuekOc605q5RepqzsJ7w6O po3DYQrtZ8x0g== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Drdte2nwPUoM for ; Wed, 13 Jun 2018 09:55:33 -0300 (ART) Received: from tclmail6.telecentro.local (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0E9F8FAC49B for ; Wed, 13 Jun 2018 09:55:32 -0300 (ART) Date: Wed, 13 Jun 2018 09:55:32 -0300 (ART) From: Alejandro D'Egidio To: "v6ops@ietf.org WG" Message-ID: <978234627.61446414.1528894532614.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3474df81-ccd3-42f9-b02c-fbd4bebd8dc3" X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - GC67 (Win)/8.7.0_GA_1659) Thread-Topic: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Thread-Index: JqQJ7h0wAlvM22iDXgGxt+OEH2tK+g== Archived-At: Subject: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 12:55:47 -0000 --=_3474df81-ccd3-42f9-b02c-fbd4bebd8dc3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Lorenzo,=20 I really appreciate your comments but if you don't like 464XLAT it doesn't = mean that I can have the choice to use it. I like the idea to have CLAT fun= ctionality in CPE.=20 I think ISPs should have the chance to decide which transition method works= better on its network and infrastructure.=20 Regards,=20 ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025=C2=A0 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC)=20 De: "JORDI PALET MARTINEZ" = =20 Para: "Lorenzo Colitti" , lencse@hit= .bme.hu=20 CC: "v6ops@ietf.org WG" =20 Enviados: Mi=C3=A9rcoles, 13 de Junio 2018 9:21:17=20 Asunto: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition= technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6o= ps-transition-ipv4aas=20 Resending as my email client formatted it weirdly =E2=80=A6 and adding one = more comment.=20 This always depends on your perspective, network, user requirements, etc. D= ifferent operators have different requirements.=20 Here are a few disadvantages of 464xlat:=20 =C2=B7 It consumes lots of state on the NAT64 (one state table entry for ev= ery connection). MAP is much better since it uses port ranges.=20 Some ISPs care less about state and care more about having a better usage o= f each IPv4 address and providing as many ports as the users need automatic= ally.=20 With NAT64, you have for each user as many ports as they need, nothing =E2= =80=9Cextra=E2=80=9D to configure for each user. With MAP you pre-define a = number of ports per user.=20 Consequently, with NAT64 you make a much better usage of every single IPv4 = address, because they become shared based dynamically on =E2=80=9Creal-flow= -per-port=E2=80=9D needs at each given time.=20 =C2=B7 It doesn't allow any inbound connections unless the NAT cooperates. = MAP is better in the sense that you can at least receive connections within= your port range.=20 Some ISPs don=E2=80=99t want inbound connections to be statically managed b= y users, they offer different services with different prices, etc. I=E2=80= =99m not saying I agree with that. Even do, you have ways to cooperate with= the NAT64, PCP, etc., to do that. Even for corporate users you can mix tha= t with SIIT-DC or alike functions.=20 Inbound connections in your port range is useless for most of the users, or= apps or devices, because they don=E2=80=99t allow other ports, and yes, yo= u can sometimes play tricks with the CPE port forwarding, etc., etc.=20 =C2=B7 The transformation is lossy because there are IPv4 header fields tha= t cannot be translated. MAP-E is better because the encapsulation preserves= the original packet header.=20 None of the transition mechanisms can be perfect, except probably dual-stac= k, but we know we can=E2=80=99t do dual-stack for every possible network, b= ecause we don=E2=80=99t have sufficient addresses, right?=20 Now, this has been said many times, and I don=E2=80=99t necessarily agree i= nitially, but I=E2=80=99ve started to change my mind in the last few years.= ***We DON=E2=80=99T WANT a perfect transition mechanism.***=20 We want some apps to fail, so indirectly it forces to developers and conten= t providers to move them to IPv6.=20 So, all them are imperfect in one way or another, but having a single one, = is much better, cheaper and easier, from all the perspectives that having m= any. Developers will fix easier anything for a single mechanism than for ma= ny, everything will happen faster, and of course, since 464XLAT is the one = with has more users worldwide, it makes sense to push for that one everywhe= re, because the problems that the app developers find in the cellular world= , will be sorted out, so those apps will be fixed for both, cellular and no= n-cellular.=20 Also, an operator with both, cellular and non-cellular networks, is very in= terested to support a single mechanism instead of two or more. Even an oper= ator without a cellular network, many times need to provide backup by means= of LTE and that means hybrid routers with both wired and LTE interfaces. I= t is much simpler to have a single mechanism for both, because even the cel= lular network is not its own network, it can use the same NAT64 (or the sam= e outsourced one for both kind of connections).=20 I was not a fan of 464XLAT initially when it was developed, but market make= me change my mind.=20 In summary, it all depends on your perspective, but if our goal is to push = as much as possible for a higher % of IPv6-only traffic, I=E2=80=99m convin= ced cellular networks, which are the ones with higher % of penetration and = growth, clearly defined the path that we must follow.=20 On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor < [ mailto:lencse@hit.bme= .hu | lencse@hit.bme.hu ] > wrote:=20 Dear Lorenzo,=20 I think it is a rather strong statement that "464XLAT is pretty much the wo= rse of the transition mechanisms from a technical perspective."=20 We have listed 26+ IPv6 transition technologies in our workshop paper [1], = but there are even more solutions exist.=20 Which of them do you mean to be better than 464XLAT?=20 What technical points do you consider when stating that 464XLAT is worse th= an the others? (E.g. resource consumption, scalability, security, ease of i= mplementation, etc.)=20 I think it is important for network operators to have a balanced view of th= e advantages and disadvantages of the different IPv6 transition mechanisms,= this is why I am asking these questions.=20 Best regards,=20 G=C3=A1bor Lencse=20 [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies f= or Security Analysis", IEICE Communications Society Internet Architecture W= orkshop, Tokyo, Japan, Aug.. 28, 2017, IEICE Tech. Rep. , vol. 117, no. 187= , pp. 19-24. Available online: [ http://www.hit.bme.hu/~lencse/publications= /IEICE-IA-2017-survey.pdf | http://www.hit.bme.hu/~lencse/publications/IEIC= E-IA-2017-survey.pdf ]=20 6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenzo Colitti =C3=ADrta:=20 BQ_BEGIN That goes back to my earlier point of that from a technical perspective 464= xlat is pretty much the worst of the transition mechanisms.. I don't think = we should be recommending running it on wireline at all, let alone prioriti= zing it over something else .:-)=20 On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ wr= ote:=20 BQ_BEGIN Lorenzo, you=E2=80=99re missing the key aspect: Being able to prioritize, w= hen an ISP supports several transition mechanisms.=20 RFC8026 key aspect is priority. If we don=E2=80=99t add an option code for = 464XLAT, then it can=E2=80=99t be managed the same way.=20 Regards,=20 Jordi=20 De: v6ops < [ mailto:v6ops-bounces@ietf.org | v6ops-bounces@ietf.org ] > en= nombre de Lorenzo Colitti =20 Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 4:45=20 Para: =20 CC: " [ mailto:v6ops@ietf.org | v6ops@ietf.org ] WG" < [ mailto:v6ops@ietf.= org | v6ops@ietf.org ] >=20 Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops= -transition-ipv4aas=20 On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ w= rote:=20 BQ_BEGIN You don=E2=80=99t need RFC7050 neither DNS64, you can use PCP (RFC7225) to = tell the CLAT the NAT64 prefix. It also provides additional advantages to t= he operator to control many related aspects (see section 3 of RFC7225).=20 1. If the operator wants to enable 464xlat: they should hand out a DNS64 to= the CPE.=20 2. If the operator wants to disable 464xlat: they should NOT hand out a DNS= 64 to the CPE.=20 This doesn=E2=80=99t work, because the operator may be using RFC7225 instea= d of RFC7050. You need to try both in that case, and you aren=E2=80=99t pro= viding a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which= is what RFC8026 does.=20 But it's the same problem again: what's the use case for this DHCPv6 option= ? An operator that's using RFC7225 has an easy way to tell the CPE not to d= o 464xlat: don't hand out the prefix64 to those CPEs. So this is already po= ssible today.=20 BQ_BEGIN 3. If the operator uses 464xlat, they should not allow the user to change t= he DNS server.=20 Let=E2=80=99s be realistic. You can=E2=80=99t =E2=80=9Cforce=E2=80=9D the c= ustomer to avoid changing the DNS =E2=80=A6=20 BQ_END On an operator-managed CPE, you can. On a user-managed CPE, you can't. But = on such a CPE you probably shouldn't be disabling 464xlat. If the user want= s to use it, it's their CPE, right?=20 _______________________________________________ v6ops mailing list [ mailto= :v6ops@ietf.org | v6ops@ietf..org ] [ https://www.ietf.org/mailman/listinfo= /v6ops | https://www.ietf.org/mailman/listinfo/v6ops ]=20 **********************************************=20 IPv4 is over=20 Are you ready for the new Internet ?=20 [ http://www.consulintel.es/ | http://www.consulintel.es ]=20 The IPv6 Company=20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.=20 BQ_END _______________________________________________=20 v6ops mailing list=20 [ mailto:v6ops@ietf.org | v6ops@ietf.org ]=20 [ https://www.ietf.org/mailman/listinfo/v6ops | https://www.ietf.org/mailma= n/listinfo/v6ops ]=20 BQ_END _______________________________________________=20 v6ops mailing list=20 [ mailto:v6ops@ietf.org | v6ops@ietf.org ]=20 [ https://www.ietf.org/mailman/listinfo/v6ops | https://www.ietf.org/mailma= n/listinfo/v6ops ]=20 BQ_END _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 **********************************************=20 IPv4 is over=20 Are you ready for the new Internet ?=20 http://www.consulintel.es=20 The IPv6 Company=20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.=20 _______________________________________________=20 v6ops mailing list=20 v6ops@ietf.org=20 https://www.ietf.org/mailman/listinfo/v6ops=20 --=_3474df81-ccd3-42f9-b02c-fbd4bebd8dc3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Lorenzo,
I really appreciate your co= mments but if you don't like 464XLAT it doesn't mean that I can have the ch= oice to use it. I like the idea to have CLAT functionality in CPE.
I think ISPs should have the chance to decide which transition method wor= ks better on its network and infrastructure.


Regards,

ALEJANDRO D'EGIDI=
O
Jefe de Ingenier=C3=ADa de Backbone
F: +54 11=
 3977 1025  | M: +54 911 5794 1589
Lavard=C3=
=A9n 157. Piso 3. CABA (C1437FBC)
<= /div>

De: "JORDI PALET MARTINEZ" <jordi.palet=3D= 40consulintel.es@dmarc.ietf.org>
Para: "Lorenzo Colitti" <l= orenzo=3D40google.com@dmarc.ietf.org>, lencse@hit.bme.hu
CC: "= v6ops@ietf.org WG" <v6ops@ietf.org>
Enviados: Mi=C3=A9rcole= s, 13 de Junio 2018 9:21:17
Asunto: Re: [v6ops] Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
<= br>
<= p class=3D"MsoNormal">Resending as my email client for= matted it weirdly =E2=80=A6 and adding one more comment.

 

This always depends on your perspective, network, use= r requirements, etc. Different operators have different requirements.

 

Here are a few disadvantages of 464xlat:

=C2=B7It consumes lots of state on the NAT64 (one state table e= ntry for every connection). MAP is much better since it uses port ra= nges.

 

Some ISPs care less about state and care more about having= a better usage of each IPv4 address and providing as many ports as the use= rs need automatically.

 

With NAT64, you have for each user= as many ports as they need, nothing =E2=80=9Cextra=E2=80=9D to configure f= or each user. With MAP you pre-define a number of ports per user.

 

Consequently, with NAT64 you make a much better usage of every s= ingle IPv4 address, because they become shared based dynamically on =E2=80= =9Creal-flow-per-port=E2=80=9D needs at each given time.

 

=  

=C2=B7<= span style=3D"font: 7.0pt 'Times New Roman';" data-mce-style=3D"font: 7.0pt= 'Times New Roman';">         It doesn't allow any inbound connectio= ns unless the NAT cooperates. MAP is better in the sense that you can at le= ast receive connections within your port range.

 

Some ISPs= don=E2=80=99t want inbound connections to be statically managed by users, = they offer different services with different prices, etc. I=E2=80=99m not s= aying I agree with that. Even do, you have ways to cooperate with the NAT64= , PCP, etc., to do that. Even for corporate users you can mix that with SII= T-DC or alike functions.

 <= /span>

Inbound connections in your port= range is useless for most of the users, or apps or devices, because they d= on=E2=80=99t allow other ports, and yes, you can sometimes play tricks with= the CPE port forwarding, etc., etc.

=C2=B7   &nbs= p;     The tr= ansformation is lossy because there are IPv4 header fields that cannot be t= ranslated. MAP-E is better because the encapsulation preserves the original= packet header.

 

None of the transition mechanisms can be = perfect, except probably dual-stack, but we know we can=E2=80=99t do dual-s= tack for every possible network, because we don=E2=80=99t have sufficient a= ddresses, right?

 

Now, this has been said many times, and = I don=E2=80=99t necessarily agree initially, but I=E2=80=99ve started to ch= ange my mind in the last few years. ***We DON=E2=80=99T WANT a perfect tran= sition mechanism.***

 

We want some apps to fail, so indire= ctly it forces to developers and content providers to move them to IPv6.

 

So, all them are imperfect in one way or another, but havin= g a single one, is much better, cheaper and easier, from all the perspectiv= es that having many. Developers will fix easier anything for a single mecha= nism than for many, everything will happen faster, and of course, since 464= XLAT is the one with has more users worldwide, it makes sense to push for t= hat one everywhere, because the problems that the app developers find in th= e cellular world, will be sorted out, so those apps will be fixed for both,= cellular and non-cellular.

&nbs= p;

Also, an operator with both, = cellular and non-cellular networks, is very interested to support a single = mechanism instead of two or more. Even an operator without a cellular netwo= rk, many times need to provide backup by means of LTE and that means hybrid= routers with both wired and LTE interfaces. It is much simpler to have a s= ingle mechanism for both, because even the cellular network is not its own = network, it can use the same NAT64 (or the same outsourced one for both kin= d of connections).

 =

I was not a fan of 464XLAT initially w= hen it was developed, but market make me change my mind.

 

= In summary, it all depends on your perspective, but if our goal is to push = as much as possible for a higher % of IPv6-only traffic, I=E2=80=99m convin= ced cellular networks, which are the ones with higher % of penetration and = growth, clearly defined the path that we must follow.

 

 

On Wed, Jun 13, 2018 at 6:12 PM Lencse G=C3=A1bor <= lencse@hit.bme.hu> wrote:

Dear Lorenzo,=

I think it is a rather strong statement that "464XLAT is pretty muc= h the worse of the transition mechanisms from a technical perspective."
=
We have listed 26+ IPv6 transition technologies in our workshop paper [= 1], but there are even more solutions exist.

Which of them do you m= ean to be better than 464XLAT?

What technical points do you consider= when stating that 464XLAT is worse than the others? (E.g. resource consump= tion, scalability, security, ease of implementation, etc.)

I think i= t is important for network operators to have a balanced view of the advanta= ges and disadvantages of the different IPv6 transition mechanisms, this is = why I am asking these questions.

Best regards,

G=C3=A1bor Len= cse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition= Technologies for Security Analysis", IEICE Communications Society Internet= Architecture Workshop, Tokyo, Japan, Aug.. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEIC= E-IA-2017-survey.pdf

6/13/2018 9:38 AM keltez=C3=A9ssel, Lorenz= o Colitti =C3=ADrta:

That goes back t= o my earlier point of that from a technical perspective 464xlat is pretty m= uch the worst of the transition mechanisms.. I don't think we should be rec= ommending running it on wireline at all, let alone prioritizing it over som= ething else .:-)

&n= bsp;

On Wed, Ju= n 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org>= wrote:

Lorenzo, yo= u=E2=80=99re missing the key aspect: Being able to prioritize, when an ISP = supports several transition mechanisms.

 

RFC8026 = key aspect is priority. If we don=E2=80=99t add an option code for 464XLAT,= then it can=E2=80=99t be managed the same way.


Regards,

Jordi

 

 

 

De: v6ops <<= a href=3D"mailto:v6ops-bounces@ietf.org" target=3D"_blank">v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org>
Fecha: mi=C3=A9rcoles= , 13 de junio de 2018, 4:45
Para: <jordi.palet=3D40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@iet= f.org>
= Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v= 6ops-transition-ipv4aas

&n= bsp;

On Tue, Jun 12, 2018 at 7:40 PM JORDI P= ALET MARTINEZ <jordi.palet=3D40consulintel..es@dma= rc.ietf.org> wrote:

You don=E2=80=99t need RFC7050 neither = DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also= provides additional advantages to the operator to control many related asp= ects (see section 3 of RFC7225).

 

1.  = ;     If the operator wants to enable 464xlat: they sho= uld hand out a DNS64 to the CPE.

2.    &nbs= p;  If the operator wants to disable 464xlat: they should NOT han= d out a DNS64 to the CPE.

This doesn=E2=80=99t work, because the = operator may be using RFC7225 instead of RFC7050. You need to try both in t= hat case, and you aren=E2=80=99t providing a =E2=80=9Cpriority=E2=80=9D to = a possible list of mechanisms, which is what RFC8026 does.

=

 

But it's the same probl= em again: what's the use case for this DHCPv6 option? An operator that's us= ing RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand o= ut the prefix64 to those CPEs. So this is already possible today.

  

3.       If the operator uses 464xlat= , they should not allow the user to change the DNS server.

 =

 

Let=E2=80=99s be realistic. You can=E2=80=99t = =E2=80=9Cforce=E2=80=9D the customer to avoid changing the DNS =E2=80=A6

 

On an = operator-managed CPE, you can. On a user-managed CPE, you can't. But on suc= h a CPE you probably shouldn't be disabling 464xlat. If the user wants to u= se it, it's their CPE, right?

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


= **********************************************
IPv4 is over
Are you r= eady for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message c= ontains information which may be privileged or confidential. The informatio= n is intended to be for the exclusive use of the individual(s) named above = and further non-explicilty authorized disclosure, copying, distribution or = use of the contents of this information, even if partially, including attac= hed files, is strictly prohibited and will be considered a criminal offense= . If you are not the intended recipient be aware that any disclosure, copyi= ng, distribution or use of the contents of this information, even if partia= lly, including attached files, is strictly prohibited, will be considered a= criminal offense, so you must reply to the original sender to inform about= this communication and delete it.

 

_________________=
______________________________
v6ops mail=
ing list
<=
span lang=3D"EN-US">v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops=

 

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

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

<= br>**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.


_______________________________________________
v6ops mailing listv6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--=_3474df81-ccd3-42f9-b02c-fbd4bebd8dc3-- From nobody Wed Jun 13 06:32: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 F2978130E37 for ; Wed, 13 Jun 2018 06:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2lnAAhYtPfcN for ; Wed, 13 Jun 2018 06:31:54 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B585130E2A for ; Wed, 13 Jun 2018 06:31:54 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w7-v6so2781001wrn.6 for ; Wed, 13 Jun 2018 06:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=s1IkAV7rVQZMiIvXF4IdzBXwN5U9CnJi6AT6B36jlNM=; b=qM0zHJy1CpVXeF13HmtTNyVV65C8G4ITNoWYnlCP469Q56l9117ZY4A1M4jxkUCUJk kSILhmrCORpVNFPrsMn/qSGlQjOjxEqCfyhCkq47k3bkyWtzAzv2EKMgC1Vgreu8HZbv wBXMmYds9DmjdRl+g6WT+ptA1/Engaic9E23zFVzDAXP6fxaSukNaHKERB5WLpSgNpfW wArJxCROFzFzMLrvyG4CCbn1ku7x+w5RTOICULWvqDlVKOQOKtGPkJjvtV0g+G9IfqA8 lyLVg391RqXRvITdjVqXO2lvdgOBIifgCvCS0p5HeKeh6GmKI9kgjGt36YFMeZszl0RB P8kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=s1IkAV7rVQZMiIvXF4IdzBXwN5U9CnJi6AT6B36jlNM=; b=EfjsuVLkCess0c0h3ZTVBRI3dlddHKDP8II5aRP55u4Ubf2WV9FMtUieZtq1djxND5 9bB/I//ZYiwK23Mxw/FT5Kd0NSCA4WyM4TE/EC9YAMnSx2OoxHpcCiDhVRmS4v+HGg6+ oaTD0Cwo9t23ZCrx9ioCOW1mMtoL3GV6Bu+gZ7VfKCk2BvFg0jaxxaJEaUppdqOoqZYK LEaEDNy3f4Kpgaod2RrqtWQCOv+yHv+wfdyM7hfjjPE6Kfd03FxeuHCSl81yi7ezzoRV F8P2O+h1P9J2zGFMH1U8ERpKHgDoVTy7Rr6OLhzONMsCUFCfXK4YGdSN+h4vKVDAJ+Ew FbJw== X-Gm-Message-State: APt69E1v4B9hlH6og1tp/7RNLT0JVqwq4H+G63sOGG7S3gUJT8m7uxwg hKEI8sDo6h5E7xEIXr0vbh/zgg== X-Google-Smtp-Source: ADUXVKKnLEBgzlyUxMNEceYzVUtkbQBs/ffgfG1sJ0SCii3QDeVZ6T0DnLXHgXPQUkGDhw6URHdfXA== X-Received: by 2002:adf:d10a:: with SMTP id a10-v6mr4063470wri.18.1528896712955; Wed, 13 Jun 2018 06:31:52 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2c:2f:3db9:641:5f8e:385? (2a01cb099f2c002f3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2c:2f:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id r5-v6sm2104971wrp.59.2018.06.13.06.31.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 06:31:52 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: "v6ops@ietf.org" Message-ID: Date: Wed, 13 Jun 2018 15:31:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9FD81B9698EBE2571582D8B8" Content-Language: fr Archived-At: Subject: [v6ops] Apple itunes is not on IPv6? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:31:58 -0000 This is a multi-part message in MIME format. --------------9FD81B9698EBE2571582D8B8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The IETF meeting agenda offers apps for Android and iPhone. It seems the iPhone app can not be accessed if connecting from a machine that does only IPv6 (Windows with IPv4 unchecked, on a cellular access network with PDP type IPv6). https://itunes.apple.com/us/app/ietfers/id449400097?mt=8 If I check IPv4 back on on Windows, and connect to another cellular network with PDP type IPv4 (instead of IPv6) then that itunes link works ok. Alex --------------9FD81B9698EBE2571582D8B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The IETF meeting agenda offers apps for Android and iPhone. 

It seems the iPhone app can not be accessed if connecting from a machine that does only IPv6 (Windows with IPv4 unchecked, on a cellular access network with PDP type IPv6).

https://itunes.apple.com/us/app/ietfers/id449400097?mt=8

If I check IPv4 back on on Windows, and connect to another cellular network with PDP type IPv4 (instead of IPv6) then that itunes link works ok.

Alex

--------------9FD81B9698EBE2571582D8B8-- From nobody Wed Jun 13 06:40:20 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 C49DA130F1F for ; Wed, 13 Jun 2018 06:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 cgvt-zKEYHxo for ; Wed, 13 Jun 2018 06:40:05 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD0E130F55 for ; Wed, 13 Jun 2018 06:40:04 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k16-v6so2827549wro.0 for ; Wed, 13 Jun 2018 06:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=T1gpJKHGgpF6mijMnuZKjG2hGGSxoyZxPNYDXenrzgM=; b=lUMe0jwGVMAlm/EukvsBbcY09rsGdE8eKH6BDwZdkGxlbiqi1OgKJzsYAGxRL3Sp5/ 5weqCx8ye/KMAz58Jz8THBF4YRXbN1gD7+8lHYT/hhCeHfhAdiCIKp7eC7tnAf/sCDH/ xZNW+X902ONH65EdOoeXm9j1fDU91hSA+0rB300i9Gs9CvBtFBulz5jFoMo1cqsWgk+t 7MeBtCTQrMFxUmYd8OjFU1HGmjU9our1l0sQ5AAKWWjElU95t4IPShFSZu5g08BQ5KZi BVzB08UC3qTNLsmK127eYCL9A0yJrjKhsc/9H3P4nYR2l8mIi/cY06uwGU0/1FQ0oew1 Be7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=T1gpJKHGgpF6mijMnuZKjG2hGGSxoyZxPNYDXenrzgM=; b=iCOv/EqkkXhHHi4Xs8hh2CWVLp8UMFI2vPiFjkgu39wWaV7tIHs+bKWXJTV7X5rBjU 3HqnKlFbCLmabmSis7Fx+bz8ln3wc1vEIcQmvm9GgqzqgrYXbO558eTVjjtoXTr0Ikza T/PloJQOVBEhxN9JjHHXo2+NuqiP8T4N5JEVg0bj3SS+2soDQ3LLZXLyniiLX5+r3ruC tp5FovIWBwIiVZ6tKnnjdxYtKuoPh3kA8nFDFv2znjfvrDjHhOZYOCQb+Jl1xVsBvaVl t1QtwE0Y7rbfvMJlf20WzEh/s9nd8o6UVnjirlz7l0hoJLUfxTXvOh19VtKqgPRyU4TS qKCg== X-Gm-Message-State: APt69E2bOk1ElxvZofUCFAsZPifCSGme+bJu4PXZ7oH0WumggeeKc6kR uCIUhzlpw+JaIO61mwM+bl4twg== X-Google-Smtp-Source: ADUXVKL+Y89JRHqARQLyISHgbxXokdUwGTC+EElyMk+84UuuXLS/u1kIA8o1QvYDZuYMPW/q4qRXVw== X-Received: by 2002:adf:9dc9:: with SMTP id q9-v6mr4415714wre.12.1528897203287; Wed, 13 Jun 2018 06:40:03 -0700 (PDT) Received: from ?IPv6:2a01:cb09:9f2c:2f:3db9:641:5f8e:385? (2a01cb099f2c002f3db906415f8e0385.ipv6.abo.wanadoo.fr. [2a01:cb09:9f2c:2f:3db9:641:5f8e:385]) by smtp.gmail.com with ESMTPSA id z3-v6sm2988826wrn.42.2018.06.13.06.40.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 06:40:02 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: "v6ops@ietf.org" References: Message-ID: <0782c3ba-9118-e425-ea68-b7261da06220@gmail.com> Date: Wed, 13 Jun 2018 15:40:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------215EEC71A326611DDFCB40DB" Content-Language: fr Archived-At: Subject: Re: [v6ops] Apple itunes is on IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:40:18 -0000 This is a multi-part message in MIME format. --------------215EEC71A326611DDFCB40DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sorry, talking to myself. Yes itunes is on IPv6 and yes the agenda on apple devices is downloadable on IPv6 Earlier there was some other problem (may be some DNS issue or Windows http or so). Alex Le 13/06/2018 à 15:31, Alexandre Petrescu a écrit : > > The IETF meeting agenda offers apps for Android and iPhone. > > It seems the iPhone app can not be accessed if connecting from a > machine that does only IPv6 (Windows with IPv4 unchecked, on a > cellular access network with PDP type IPv6). > > https://itunes.apple.com/us/app/ietfers/id449400097?mt=8 > > If I check IPv4 back on on Windows, and connect to another cellular > network with PDP type IPv4 (instead of IPv6) then that itunes link > works ok. > > Alex > --------------215EEC71A326611DDFCB40DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sorry, talking to myself.

Yes itunes is on IPv6 and yes the agenda on apple devices is downloadable on IPv6

Earlier there was some other problem (may be some DNS issue or Windows http or so).

Alex

Le 13/06/2018 à 15:31, Alexandre Petrescu a écrit :

The IETF meeting agenda offers apps for Android and iPhone. 

It seems the iPhone app can not be accessed if connecting from a machine that does only IPv6 (Windows with IPv4 unchecked, on a cellular access network with PDP type IPv6).

https://itunes.apple.com/us/app/ietfers/id449400097?mt=8

If I check IPv4 back on on Windows, and connect to another cellular network with PDP type IPv4 (instead of IPv6) then that itunes link works ok.

Alex


--------------215EEC71A326611DDFCB40DB-- From nobody Wed Jun 13 08:02:10 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 6CFF6130E37 for ; Wed, 13 Jun 2018 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFnDm-TyD6OI for ; Wed, 13 Jun 2018 08:01:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E644130E26 for ; Wed, 13 Jun 2018 08:01:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HVAQDPMCFb/wUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ1U4FPEigKmFyBf5RpFIFkCyyEQAKCOCE2FgECAQEBAQEBAgI?= =?us-ascii?q?CaSiFKgEBAQEDEigxDAIMBAIBCA0BAwQBAQEKFAkHMhQJCAIEDgUIGoUBAaIJj?= =?us-ascii?q?AgaAogqgWiIS4FVPoQbhEABEgEDBhiDMIIkApkKCQKXDoUfkT2BSAcrYXFwFTu?= =?us-ascii?q?CQ4JJjgZvgRWLXIEfAYEZAQE?= X-IPAS-Result: =?us-ascii?q?A2HVAQDPMCFb/wUHmMZdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?1U4FPEigKmFyBf5RpFIFkCyyEQAKCOCE2FgECAQEBAQEBAgICaSiFKgEBAQEDE?= =?us-ascii?q?igxDAIMBAIBCA0BAwQBAQEKFAkHMhQJCAIEDgUIGoUBAaIJjAgaAogqgWiIS4F?= =?us-ascii?q?VPoQbhEABEgEDBhiDMIIkApkKCQKXDoUfkT2BSAcrYXFwFTuCQ4JJjgZvgRWLX?= =?us-ascii?q?IEfAYEZAQE?= X-IronPort-AV: E=Sophos;i="5.51,219,1526356800"; d="scan'208";a="284366223" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Jun 2018 11:01:56 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 11:01:56 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0382.000; Wed, 13 Jun 2018 11:01:56 -0400 From: "Mudric, Dusan (Dusan)" To: Mikael Abrahamsson CC: Richard Patterson , "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt Thread-Index: AQHUAtP9Q+0soWtnZE2MJIS2QBWzJqReSJUA Date: Wed, 13 Jun 2018 15:01:55 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB0867C@AZ-US1EXMB03.global.avaya.com> References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB08439@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 15:02:03 -0000 I expect the server to deliver the same prefix, if the client is using PD t= o create the addresses. But I would not expect the server to offer the addr= ess already in use, unless the server check the client identifier and is ab= le to figure out which address is used by the client. Dusan > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Wednesday, June 13, 2018 1:04 AM > To: Mudric, Dusan (Dusan) > Cc: Richard Patterson ; v6ops@ietf.org list > > Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea= - > ipoe-health-01.txt >=20 > On Tue, 12 Jun 2018, Mudric, Dusan (Dusan) wrote: >=20 > > lease. Considering the lease will not be RELEASE-d, the server will not > > offer the lease for the new solicitation. The client should use Server >=20 > Hm, I am not an DHCPv6 expert, but in my experience if I power off a > device with an active lease, power it on again, it comes up again and doe= s > SOLICIT, it will get the same prefix back that it had before the power > off (it does not provide any prefix information in the solicit). >=20 > What am I missing here? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 13 09:51: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 D37B7130ECE; Wed, 13 Jun 2018 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtEWh_HkdPN9; Wed, 13 Jun 2018 09:46:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0585130E6C; Wed, 13 Jun 2018 09:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528908370; x=1529513170; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=HkBo4+1LxcgUpt9tUPeA8 7UK+rvGiGdkdGgm07LpJKE=; b=YfnU7AfJX7j4+aqugcGUtrMk3Mtx2dooXVPK1 jhJoVfDzetlVB7D0WNz6Rv4MPoH06CYr8u0T/k7aRBAYjahm2OsrofBPbyVkMByW gXLEX54dmq4/WqTBVAoWeYGwUBgnuBu11xNf9b8NSAcmkx2+lLGQKJMSA7OIt2+g Forb2U= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 18:46:10 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 18:46:10 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788924.msg; Wed, 13 Jun 2018 18:46:09 +0200 X-MDRemoteIP: 2001:470:1f09:495:c0a2:a933:6e2:70df X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 18:46:09 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 18:46:08 +0200 From: JORDI PALET MARTINEZ To: , , Message-ID: <26F14014-305A-4521-A657-7CB746A4309B@consulintel.es> Thread-Topic: updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 16:46:20 -0000 Hi all, I'm sending this to Sotfwires and DHC WGs, in order to let know and seek review, but please keep the discussion only in v6ops which is responsible of this document https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Here is the short summary of the reasons for the update. In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) transition mechanisms (so the ISP can "agree" with each CPE which one to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is a DHCPv6 based mechanism. The interesting issue is that because 464XLAT don't have an option code in RFC8026, it can't be ranked the same way, and ideally it should be, as we use also that in order to facilitate the operator to "manage" each transition mechanism status to be on/off (even to different customers). So, what we do with this update, is adding that option code for 464XLAT to the existing ones and instruct IANA about that. If you want to understand the suggested updated and how our algorithm works, you can read directly section 3.3, 7 and 10. Of course, inputs on the complete document are welcome! Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Wed Jun 13 10:01: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 0EE27130ED7 for ; Wed, 13 Jun 2018 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs8_1Bsc7C7q for ; Wed, 13 Jun 2018 10:01:03 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E781B130E6C for ; Wed, 13 Jun 2018 10:01:02 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-41-164.kabelnet.hu [79.121.41.164]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5DH0lAk092941 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 13 Jun 2018 19:00:54 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-164.kabelnet.hu [79.121.41.164] claimed to be [192.168.1.114] References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= To: "v6ops@ietf.org WG" Message-ID: <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> Date: Wed, 13 Jun 2018 19:00:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------05ED525C9D61393CB696F96D" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.164; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 17:01:07 -0000 This is a multi-part message in MIME format. --------------05ED525C9D61393CB696F96D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Lorenzo, Thank you very much for your answer. For a balanced view, I think it is useful to point out that the MAP protocols have their disadvantages, too. _1. Port numbers_ As Jordi has already pointed it out, one needs to dedicate a fix number of ports per CPE. Some advice that a few hundred will do for this value, but I think that it is not so simple: - The lack of port situation may cause serious problems in the operation of certain programs, for more information see [1]. - The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors [2]. - There may be several users behind a CPE, especially in the wired case (e.g. Internet is used by different members of a family simultaneously), thus sometimes even a few thousands may not be enough. Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public IP addresses) much more economically. _2. Complexity and security_ The operation of the MAP solution is rather complex, now I give only some highlights. Let us consider MAP-T. (MAP-E works similarly, but it uses encapsulation.) "First, the MAP-T CE (Customer Edge) device performs a NAT44 operation to restrict the available TCP/UDP port numbers for the user. Then the CE device performs a special stateless translation from IPv4 to IPv6, where the source IPv4 address and the selected port bits are encoded into the source IPv6 address according to the MAP-T rules. The IPv6 packets can be destined to other users, where similar CEs perform the necessary transformations, or to the outside IPv4 Internet, in which case the MAP-T Border Relay performs the necessary transformations." [3] This complexity has performance and security implications: - Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, which can be inspected e.g. by firewalls, the IPv6 backbone traffic of MAP-T (as well as that of MAP-E) needs to be first "decoded", which causes further costs (both CAPEX and OPEX). - Complex code may contain more bugs and thus also security holes. (In the simplest model, the number of bugs is proportional to the number of code lines.) _3. MAP-T and MAP-E are different_ On the one hand, if double translation may cause the loss of some IPv4 fields (BTW: What exactly did you mean?), then it is also applies for MAP-T. On the other hand, MAP-E uses encapsulation, which results in an overhead. An IPv6 header is at least 40 bytes, which may be a significant overhead in the case of small packets, e.g. TCP acknowledgments. _4. What other IPv6 transition solutions did you also consider?_ As you have now mentioned only MAP, I wonder what other solutions you could consider better than 464XLAT? Best regards, Gábor Lencse References: [1] S. Miyakawa, "IPv4 to IPv6 transformation schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. DOI:10.1587/transcom.E93.B.1078 [2] S. Répás, T. Hajas, and G. Lencse, "Port number consumption of the NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411 [3] G. Lencse, Y. Kadobayashi, "Comprehensive survey of IPv6 transition technologies for security analysis", unpublished 6/13/2018 12:55 PM keltezéssel, Lorenzo Colitti írta: > Here are a few disadvantages of 464xlat: > > * It consumes lots of state on the NAT64 (one state table entry for > every connection). MAP is much better since it uses port ranges. > * It doesn't allow any inbound connections unless the NAT > cooperates. MAP is better in the sense that you can at least > receive connections within your port range. > * The transformation is lossy because there are IPv4 header fields > that cannot be translated. MAP-E is better because the > encapsulation preserves the original packet header. > > > On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor > wrote: > > Dear Lorenzo, > > I think it is a rather strong statement that "464XLAT is pretty > much the worse of the transition mechanisms from a technical > perspective." > > We have listed 26+ IPv6 transition technologies in our workshop > paper [1], but there are even more solutions exist. > > Which of them do you mean to be better than 464XLAT? > > What technical points do you consider when stating that 464XLAT is > worse than the others? (E.g. resource consumption, scalability, > security, ease of implementation, etc.) > > I think it is important for network operators to have a balanced > view of the advantages and disadvantages of the different IPv6 > transition mechanisms, this is why I am asking these questions. > > Best regards, > > Gábor Lencse > > > [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition > Technologies for Security Analysis", IEICE Communications Society > Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, > /IEICE Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available > online: > http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf > > > > 6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta: >> That goes back to my earlier point of that from a technical >> perspective 464xlat is pretty much the worst of the transition >> mechanisms.. I don't think we should be recommending running it >> on wireline at all, let alone prioritizing it over something else >> .:-) >> >> On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ >> > > wrote: >> >> Lorenzo, you’re missing the key aspect: Being able to >> prioritize, when an ISP supports several transition mechanisms. >> >> RFC8026 key aspect is priority. If we don’t add an option >> code for 464XLAT, then it can’t be managed the same way. >> >> >> Regards, >> >> Jordi >> >> *De: *v6ops > > en nombre de Lorenzo Colitti >> > > >> *Fecha: *miércoles, 13 de junio de 2018, 4:45 >> *Para: *> > >> *CC: *"v6ops@ietf.org WG" >> > >> *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in >> draft-ietf-v6ops-transition-ipv4aas >> >> On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ >> > > wrote: >> >> You don’t need RFC7050 neither DNS64, you can use PCP >> (RFC7225) to tell the CLAT the NAT64 prefix. It also >> provides additional advantages to the operator to control >> many related aspects (see section 3 of RFC7225). >> >> 1.If the operator wants to enable 464xlat: they should >> hand out a DNS64 to the CPE. >> >> 2.If the operator wants to disable 464xlat: they should >> NOT hand out a DNS64 to the CPE. >> >> This doesn’t work, because the operator may be using >> RFC7225 instead of RFC7050. You need to try both in that >> case, and you aren’t providing a “priority” to a possible >> list of mechanisms, which is what RFC8026 does. >> >> But it's the same problem again: what's the use case for this >> DHCPv6 option? An operator that's using RFC7225 has an easy >> way to tell the CPE not to do 464xlat: don't hand out the >> prefix64 to those CPEs. So this is already possible today. >> >> 3.If the operator uses 464xlat, they should not allow the >> user to change the DNS server. >> >> Let’s be realistic. You can’t “force” the customer to >> avoid changing the DNS … >> >> On an operator-managed CPE, you can. On a user-managed CPE, >> you can't. But on such a CPE you probably shouldn't be >> disabling 464xlat. If the user wants to use it, it's their >> CPE, right? >> >> _______________________________________________ v6ops mailing >> list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be >> for the exclusive use of the individual(s) named above and >> further non-explicilty authorized disclosure, copying, >> distribution or use of the contents of this information, even >> if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you >> are not the intended recipient be aware that any disclosure, >> copying, distribution or use of the contents of this >> information, even if partially, including attached files, is >> strictly prohibited, will be considered a criminal offense, >> so you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ >> 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 > --------------05ED525C9D61393CB696F96D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Lorenzo,

Thank you very much for your answer.

For a balanced view, I think it is useful to point out that the MAP protocols have their disadvantages, too.

1. Port numbers

As Jordi has already pointed it out, one needs to dedicate a fix number of ports per CPE. Some advice that a few hundred will do for this value, but I think that it is not so simple:
- The lack of port situation may cause serious problems in the operation of certain programs, for more information see [1].
- The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors [2].
- There may be several users behind a CPE, especially in the wired case (e.g. Internet is used by different members of a family simultaneously), thus sometimes even a few thousands may not be enough.

Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public IP addresses) much more economically.

2. Complexity and security

The operation of the MAP solution is rather complex, now I give only some highlights. Let us consider MAP-T. (MAP-E works similarly, but it uses encapsulation.) "First, the MAP-T CE (Customer Edge) device performs a NAT44 operation to restrict the available TCP/UDP port numbers for the user.  Then the CE device performs a special stateless translation from IPv4 to IPv6, where the source IPv4 address and the selected port bits are encoded into the source IPv6 address according to the MAP-T rules. The IPv6 packets can be destined to other users, where similar CEs perform the necessary transformations, or to the outside IPv4 Internet, in which case the MAP-T Border Relay performs the necessary transformations." [3]

This complexity has performance and security implications:
- Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, which can be inspected e.g. by firewalls, the IPv6 backbone traffic of MAP-T (as well as that of MAP-E) needs to be first "decoded", which causes further costs (both CAPEX and OPEX).
-  Complex code may contain more bugs and thus also security holes. (In the simplest model, the number of bugs is proportional to the number of code lines.)

3. MAP-T and MAP-E are different

On the one hand, if double translation may cause the loss of some IPv4 fields (BTW: What exactly did you mean?), then it is also applies for MAP-T.
On the other hand, MAP-E uses encapsulation, which results in an overhead. An IPv6 header is at least 40 bytes, which may be a significant overhead in the case of small packets, e.g. TCP acknowledgments.

4. What other IPv6 transition solutions did you also consider?

As you have now mentioned only MAP,  I wonder what other solutions you could consider better than 464XLAT?

Best regards,

Gábor Lencse

References:
[1] S. Miyakawa, "IPv4 to IPv6 transformation schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. DOI:10.1587/transcom.E93.B.1078
[2] S. Répás, T. Hajas, and G. Lencse, "Port number consumption of the NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411
[3] G. Lencse, Y. Kadobayashi, "Comprehensive survey of IPv6 transition technologies for security analysis", unpublished

6/13/2018 12:55 PM keltezéssel, Lorenzo Colitti írta:
Here are a few disadvantages of 464xlat:
  • It consumes lots of state on the NAT64 (one state table entry for every connection). MAP is much better since it uses port ranges.
  • It doesn't allow any inbound connections unless the NAT cooperates. MAP is better in the sense that you can at least receive connections within your port range.
  • The transformation is lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserves the original packet header.

On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <lencse@hit.bme.hu> wrote:
Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf


6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta:
That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms.. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

Lorenzo, you’re missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

 

RFC8026 key aspect is priority. If we don’t add an option code for 464XLAT, then it can’t be managed the same way.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Fecha: miércoles, 13 de junio de 2018, 4:45
Para: <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel..es@dmarc.ietf.org> wrote:

You don’t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

 

1.       If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.       If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn’t work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you aren’t providing a “priority” to a possible list of mechanisms, which is what RFC8026 does.

 

But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

  

3.       If the operator uses 464xlat, they should not allow the user to change the DNS server.

 

 

Let’s be realistic. You can’t “force” the customer to avoid changing the DNS …

 

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



_______________________________________________
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

--------------05ED525C9D61393CB696F96D-- From nobody Wed Jun 13 12:37:32 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 A03BD130E87 for ; Wed, 13 Jun 2018 12:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ae4-xi7EmK1F for ; Wed, 13 Jun 2018 12:37:28 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCDB12426A for ; Wed, 13 Jun 2018 12:37:28 -0700 (PDT) Received: from h.hanazo.no (145.51-175-104.customer.lyse.net [51.175.104.145]) (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 B461C2D51D4; Wed, 13 Jun 2018 19:37:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 669992031EA72D; Wed, 13 Jun 2018 21:37:24 +0200 (CEST) From: Ole Troan Message-Id: <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_01520383-DD8E-486E-9FA9-E667687306DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 13 Jun 2018 21:37:23 +0200 In-Reply-To: <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> Cc: "v6ops@ietf.org WG" To: =?utf-8?Q?Lencse_G=C3=A1bor?= References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:37:31 -0000 --Apple-Mail=_01520383-DD8E-486E-9FA9-E667687306DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > For a balanced view, I think it is useful to point out that the MAP = protocols have their disadvantages, too. >=20 > 1. Port numbers >=20 > As Jordi has already pointed it out, one needs to dedicate a fix = number of ports per CPE. Some advice that a few hundred will do for this = value, but I think that it is not so simple: > - The lack of port situation may cause serious problems in the = operation of certain programs, for more information see [1]. > - The port number consumption of different applications is highly = varying and e.g. in the case of web browsing it depends on several = factors [2]. > - There may be several users behind a CPE, especially in the wired = case (e.g. Internet is used by different members of a family = simultaneously), thus sometimes even a few thousands may not be enough. >=20 > Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public = IP addresses) much more economically. While that is correct, you can build endpoint dependent NATs that are = extremely efficient when it comes to port utilisation. (Reusing the same port for communication to different end systems). > 2. Complexity and security >=20 > The operation of the MAP solution is rather complex, now I give only = some highlights. Let us consider MAP-T. (MAP-E works similarly, but it = uses encapsulation.) "First, the MAP-T CE (Customer Edge) device = performs a NAT44 operation to restrict the available TCP/UDP port = numbers for the user. Then the CE device performs a special stateless = translation from IPv4 to IPv6, where the source IPv4 address and the = selected port bits are encoded into the source IPv6 address according to = the MAP-T rules. The IPv6 packets can be destined to other users, where = similar CEs perform the necessary transformations, or to the outside = IPv4 Internet, in which case the MAP-T Border Relay performs the = necessary transformations." [3] >=20 > This complexity has performance and security implications: > - Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, = which can be inspected e.g. by firewalls, the IPv6 backbone traffic of = MAP-T (as well as that of MAP-E) needs to be first "decoded", which = causes further costs (both CAPEX and OPEX). This is incorrect. MAP-T IPv6 traffic is just as 'normal' as 464XLAT = IPv6 packets. > - Complex code may contain more bugs and thus also security holes. = (In the simplest model, the number of bugs is proportional to the number = of code lines.) On the PE side, stateful NAT64 is a lot more complex than any of the = MAPs. While MAP-T is somewhat more complex (in number of lines of code) = than MAP-E. You have logging considerations as well as much more complex scaling. = Scaling a MAP system is trivial. Scaling a stateful NAT system quickly = requires state synchronisation between systems. On the CPE side complexity is similar. NAT44 -> NAT46 or NAT44 -> = tunnel. (Actually the 464XLAT case where even the second NAT is stateful = is worse. > 3. MAP-T and MAP-E are different >=20 > On the one hand, if double translation may cause the loss of some IPv4 = fields (BTW: What exactly did you mean?), then it is also applies for = MAP-T. > On the other hand, MAP-E uses encapsulation, which results in an = overhead. An IPv6 header is at least 40 bytes, which may be a = significant overhead in the case of small packets, e.g. TCP = acknowledgments. Yes. At the benefit of transparency and simplicity. 464XLAT/MAP-T adds = 20 bytes, encap another 20. >=20 > 4. What other IPv6 transition solutions did you also consider? >=20 > As you have now mentioned only MAP, I wonder what other solutions you = could consider better than 464XLAT? Please don't call these IPv6 transition solutions. These solutions are about keeping IPv4 alive a little longer. The main "benefit" of 464XLAT is two-fold. It was lighter on = provisioning than e.g. MAP-E or MAP-T and it could reuse a stateful = NAT64, which could serve IPv6 only hosts reaching the IPv4 Internet. How easy it is to provision 464XLAT or NAT64 to a CE device has in = hindsight been shown to be arguable. Cheers, Ole --Apple-Mail=_01520383-DD8E-486E-9FA9-E667687306DE 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+/bDNdvtpYqJhC33YFAlshcnMACgkQvtpYqJhC 33ZnORAArYoVigVxvxIRvE7sE6V9Y+w9nFn3j0INW3o8hmbIqr+LmsMFlLIU+O9z 8QiBha6/0AGm13y/6RkJKjQWuQmKKUExFVXrIxzhHmL6iy4PGy5/Vans8mip4nZy rAqPJDbXZhw2n6LoUpLrWMzZLzcsSBB/6QqskIOpFbASJoL0NcWwuulOhtr02pZS oW5HSkKXp3nbl5n2Vtl4gUF9AywvZyYGUE+WjKc7wAxw5/guDrwV14NCeTpdKBh/ 9eTSgkJ44drDpTECneEz+zCLkqrWXxLvWz/j9ivDx6nlq2kXqcDGVW2fNRSOvVAG A9Vbq1x7BTyj4p1stDJ3v4lWgt+a2FUrElc9t/wG0e+pXqg5lKYCR5htclIJjSsd NGp3aXiAJ9z1eRHyrf26uIH8cpcguiBGH8oDcuFQoFK6jLu8S6bHIJan0aJ6WX// MgmR1LaPHBaDWOvSrvlTLDBSvAzy/TdejMVZ6f2eWPwsJHocZZFG8rXlQ+T1vidm eZWLvQaLgDwpEVibpsAq0UXxpuqPgztCYnUXC5ijzsY56v/aRHHCI+SnKteey3uf CJbtBdQ1up9CLwbLzhKKZCh5zg/W/mO4EtqXW2UmYbjVHihyXDmKPTnO/1qXEjdd OkW7idFrXXjTg8y3IDS8zrnYrH43Z+6Tx+YoSEy5M9oKVywiDE0= =e207 -----END PGP SIGNATURE----- --Apple-Mail=_01520383-DD8E-486E-9FA9-E667687306DE-- From nobody Wed Jun 13 14: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 770C4130F7E; Wed, 13 Jun 2018 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRytENBpx63J; Wed, 13 Jun 2018 14:01:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2405130E8C; Wed, 13 Jun 2018 14:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3580; q=dns/txt; s=iport; t=1528923694; x=1530133294; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JAPnaiPvDrznH3Fexl1s0RImmAGmrDdVMAEKYyhPUhE=; b=HiFzmvDphbB94ivkSAPU4df7AbPdhyXw4mo4BafTasVboVtyGl4FyCme iPfKVHo13ick05VJ5cRPBz1nSliOBxvSbtaCrofMll0xf8EUGcgJN70SY Fhg6mDbXaIpRIIBVmOAo4Cz5PvcElopJnbbICxxTPKnGsP2Idra/hq9uU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAAC3hSFb/4gNJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMeKmJ/KAqLc45olGkUgWQLGAuESQKCNyE0GAECAQEBAQE?= =?us-ascii?q?BAm0cDIUoAQEBBAEBODQXBAIBCBEEAQEfECcLHQgCBAESCIMcgX8PrnSISIF?= =?us-ascii?q?oh0GBCoITJWqDDIFBgVABAQMBgSAmJoVGAoctCAGKA4dRCQKFcnCBbYQPghO?= =?us-ascii?q?BR4N+gmiFD4drgh+HDAIREwGBJB04gVJwFTuCQwmCGBd6AQSDQYQZhT5vj0S?= =?us-ascii?q?BDwsBAQ?= X-IronPort-AV: E=Sophos;i="5.51,220,1526342400"; d="scan'208";a="399524858" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 21:01:33 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5DL1X8K009940 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2018 21:01:33 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Jun 2018 16:01:32 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Wed, 13 Jun 2018 16:01:32 -0500 From: "Bernie Volz (volz)" To: JORDI PALET MARTINEZ , "dhcwg@ietf.org" , "softwires@ietf.org" , "v6ops@ietf.org" Thread-Topic: updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUAzYGqD9KNXePNEqFHHuuI/GztKReqw0A Date: Wed, 13 Jun 2018 21:01:32 +0000 Message-ID: <7a06fa03e14649c18fcbf8cc35f1720d@XCH-ALN-003.cisco.com> References: <26F14014-305A-4521-A657-7CB746A4309B@consulintel.es> In-Reply-To: <26F14014-305A-4521-A657-7CB746A4309B@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:01:37 -0000 Hi Jordi: Haven't look at the draft in detail yet, but I did find it rather odd that = you are using option code 46. As these are DHCPv6 option codes, this maps t= o: Value Description Client ORO Singleton Option Reference 46 OPTION_CLT_TIME No Yes [RFC5007] I understand that you may have picked this simply because it is a nice numb= er for v4/v6 transition mechanisms. But it seems like a rather odd mapping. If you really think this is a wise thing to do, you should at least documen= t that you are requesting this because of its value (and because it would n= ever "really" be used for RFC 8026) - not that this OPTION_CLT_TIME option = itself has any meaning. It may be better to request that IANA assign a DHCPv6 option for this purpo= se - which should otherwise never be requested by a client (or configured o= n a server). - Bernie -----Original Message----- From: dhcwg On Behalf Of JORDI PALET MARTINEZ Sent: Wednesday, June 13, 2018 12:46 PM To: dhcwg@ietf.org; softwires@ietf.org; v6ops@ietf.org Subject: [dhcwg] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Hi all, I'm sending this to Sotfwires and DHC WGs, in order to let know and seek re= view, but please keep the discussion only in v6ops which is responsible of = this document https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Here is the short summary of the reasons for the update. In order to prioritize the different IPv4-as-a-Service (in IPv6-only networ= ks) transition mechanisms (so the ISP can "agree" with each CPE which one t= o use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prio= ritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwi= res, but it is a DHCPv6 based mechanism. The interesting issue is that because 464XLAT don't have an option code in = RFC8026, it can't be ranked the same way, and ideally it should be, as we u= se also that in order to facilitate the operator to "manage" each transitio= n mechanism status to be on/off (even to different customers). So, what we do with this update, is adding that option code for 464XLAT to = the existing ones and instruct IANA about that. If you want to understand the suggested updated and how our algorithm works= , you can read directly section 3.3, 7 and 10. Of course, inputs on the com= plete document are welcome! Thanks! Regards, Jordi =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Jun 13 14:36: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 60A4C130FCA; Wed, 13 Jun 2018 14:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5afMJR_JDEzI; Wed, 13 Jun 2018 14:36:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E92F130F83; Wed, 13 Jun 2018 14:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528925784; x=1529530584; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=NIAY0Y705T2r0qmgicUlJ O/X0wJNmkiqVqg9DQJE1AE=; b=VjQATXbqWWaLzO2wFFOOFoDAljGxLpDRSphVB M+Gh61WAN60d9op2ylczVZnq7+qtdex5seQyR+Hjb7iA9FMin+QdTXqdD3Qr/45G +qOp3PRKvI6KDOFH8Fs849NKPCd+co2MoOBHYfLPLqpDIRrEkEUZ+0R5hfFuD2pM t18/N8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 23:36:24 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 23:36:23 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789039.msg; Wed, 13 Jun 2018 23:36:21 +0200 X-MDRemoteIP: 2001:470:1f09:495:805d:c4f7:3647:ac38 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 13 Jun 2018 23:36:21 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Wed, 13 Jun 2018 23:36:19 +0200 From: JORDI PALET MARTINEZ To: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "softwires@ietf.org" , "v6ops@ietf.org" Message-ID: <574BFC33-78CD-4282-97E1-1F0D5B6B4FDD@consulintel.es> Thread-Topic: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:36:29 -0000 Hi Bernie, Thanks a lot for looking at this. I may be wrong, but I think they are different "option codes" tables and sh= ould not be a conflict. If I'm wrong it means the RFC8026 table it's just a subset, which is confus= ing when you look into the IANA web page, because looks like different tabl= es ... I was looking at https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-= parameters.xhtml There is a specific table for RFC8026 option codes: Option Code S46 Mechanism Reference=20 64 DS-Lite [RFC6334] 88 DHCPv4 over DHCPv6 [RFC7341] 94 MAP-E [RFC7598] 95 MAP-T [RFC7598] 96 Lightweight 4over6 [RFC7598] This table right now is matching the RFC8026, as no other option codes have= been added after. Those option codes (64, 88, etc.), also match other DHCPv6 option codes, in= the main table. In some cases, is very clear it has the same meaning, but = in others I'm not sure ... But of course, this is a minor detail, and as you say it looks like 46 (OPT= ION_CLT_TIME) is something never will have a conflict with RFC8026, so we c= an explicitly say that, or we can just ask IANA to assign whatever is the m= ost convenient one. I'm fine either way. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "Bernie Volz (volz)" Fecha: mi=C3=A9rcoles, 13 de junio de 2018, 23:02 Para: JORDI PALET MARTINEZ ,= "dhcwg@ietf.org" , "softwires@ietf.org" , "v6ops@ietf.org" Asunto: Re: [v6ops] updating RFC8026 with draft-ietf-v6ops-transition-ipv4a= as Hi Jordi: =20 Haven't look at the draft in detail yet, but I did find it rather odd t= hat you are using option code 46. As these are DHCPv6 option codes, this ma= ps to: =20 Value Description Client ORO Singleton Option Reference 46 OPTION_CLT_TIME No Yes [RFC5007] =20 I understand that you may have picked this simply because it is a nice = number for v4/v6 transition mechanisms. But it seems like a rather odd mapp= ing. =20 If you really think this is a wise thing to do, you should at least doc= ument that you are requesting this because of its value (and because it wou= ld never "really" be used for RFC 8026) - not that this OPTION_CLT_TIME opt= ion itself has any meaning. =20 It may be better to request that IANA assign a DHCPv6 option for this p= urpose - which should otherwise never be requested by a client (or configur= ed on a server). =20 - Bernie =20 -----Original Message----- From: dhcwg On Behalf Of JORDI PALET MARTINEZ Sent: Wednesday, June 13, 2018 12:46 PM To: dhcwg@ietf.org; softwires@ietf.org; v6ops@ietf.org Subject: [dhcwg] updating RFC8026 with draft-ietf-v6ops-transition-ipv4= aas =20 Hi all, =20 =20 =20 I'm sending this to Sotfwires and DHC WGs, in order to let know and see= k review, but please keep the discussion only in v6ops which is responsible= of this document =20 =20 =20 https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 =20 =20 Here is the short summary of the reasons for the update. =20 =20 =20 In order to prioritize the different IPv4-as-a-Service (in IPv6-only ne= tworks) transition mechanisms (so the ISP can "agree" with each CPE which o= ne to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based = Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in so= ftwires, but it is a DHCPv6 based mechanism. =20 =20 =20 The interesting issue is that because 464XLAT don't have an option code= in RFC8026, it can't be ranked the same way, and ideally it should be, as = we use also that in order to facilitate the operator to "manage" each trans= ition mechanism status to be on/off (even to different customers). =20 =20 =20 So, what we do with this update, is adding that option code for 464XLAT= to the existing ones and instruct IANA about that. =20 =20 =20 If you want to understand the suggested updated and how our algorithm w= orks, you can read directly section 3.3, 7 and 10. Of course, inputs on the= complete document are welcome! =20 =20 =20 Thanks! =20 =20 =20 Regards, =20 Jordi =20 =20 =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 13 18:15: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 34C13128CF3 for ; Wed, 13 Jun 2018 18:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 bMJX_7i0LOW8 for ; Wed, 13 Jun 2018 18:15:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE72C127AC2 for ; Wed, 13 Jun 2018 18:15:52 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5E1FNcR023349 for ; Wed, 13 Jun 2018 21:15:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2jkc9fak1m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Jun 2018 21:15:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5E1FptA013301 for ; Wed, 13 Jun 2018 21:15:51 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5E1Fnjw013295 for ; Wed, 13 Jun 2018 21:15:50 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id EC5ED4000348 for ; Thu, 14 Jun 2018 01:15:49 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30484.vci.att.com (Service) with ESMTPS id DADC74000340 for ; Thu, 14 Jun 2018 01:15:49 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0399.000; Wed, 13 Jun 2018 21:15:49 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT Thread-Index: AdQDeky6F+8pcISJQRWD/Qqdu/TGlg== Date: Thu, 14 Jun 2018 01:15:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.245.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=700 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806140012 Archived-At: Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 01:15:55 -0000 The justification presented for the request for a new DHCPv6 option 111 opt= ion code for 464XLAT was that an operator would be running multiple IPv4aas= mechanisms and needed to express which they preferred a CE router to make = use of. The discussion devolved into MAP vs. 464XLAT. The cases being made = for 464XLAT vs MAP seemed to me to make a very strong case against deployin= g multiple mechanisms. Deploying multiple mechanisms has all the downsides of all the mechanisms. = The only positive thing to say is that if the CE router supports one mechan= ism, but not the other, then the CE router is still ok. To me, this one positive aspect is such a weak reason, that I would never u= se it to justify the additional capex, opex, and customer help desk costs.= =20 Is there some better justification that I'm missing? If there is no good ju= stification for deploying 464XLAT and MAP-T or MAP-E, then why is a DHCPv6 = option 111 option code for 464XLAT needed? Barbara From nobody Wed Jun 13 19:20: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 7C2D7130FF7 for ; Wed, 13 Jun 2018 19:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6os1NzYxddW for ; Wed, 13 Jun 2018 19:19:56 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64975130FF2 for ; Wed, 13 Jun 2018 19:19:56 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id l41-v6so4663124wre.7 for ; Wed, 13 Jun 2018 19:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EOku+BVZ6URVGeTqJJ5UuSAGR2bPA1H2LADp0wufiGs=; b=f6rN74cnMLRqBrWoPOZ2ZnJ+t9CcdObRy65dTnz8IendsFskLTpHrPcjC6NXv4beUE IqUsAEnjYj37kYo0PYDRSCr0Dj15O5AALXTKXdAQYQztOk7YBtlT11pW6uMFdDLwCKiC V9/WHyE3l0qDaT31DCeRbs0h+g/m9wRiA2ycKydTtT4/WFC30wVtQeodVjClfpZHrGc8 liklFDPf+Jhp6k/GQL0teNlULDr1jHGE0mga+8gMxHLn4tHxuRmeb8351EpgPabkdNiw Iu23P3MYlOP1yrZAP3pU5VcazPIbiTQctY1qDbYWiIhPY+i8/26t/OJpGXhw1BUYFRQ2 HmPQ== 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=EOku+BVZ6URVGeTqJJ5UuSAGR2bPA1H2LADp0wufiGs=; b=kCdcIW9Yp7Y5Bv1RNvrY+G8fIXyydpa9ngiM2ok9+q8s/55BA7S+wROHiMLsVF56UO ypIA8VrtOSMqBuoRRuTeXu1mJhBEnom57687lrHaLqKav5GjV8rVZbTafSqqrCvppHB5 vGqRygDtydZi5v2f3vJInJJ91Ocf6k6X2saiYpzF7FO39JEc9PYDgXR6RxEm9lGc9PT/ b2GGJdYimbwt1R4RfWNldKd4DE5N1vvvmLmusb5lX88pnPjTbCn6UX6jR4CrQcFGFFU7 oP7ZvznAXIRTqISHevc/N9ipgt3j1+mgOj7lgko1lpLcldtGxH1DPmZdHMIMDJHw7zJ3 8bkg== X-Gm-Message-State: APt69E1EnTaUphFDE1AsFzMCGD7fWvydW9pT9N03TqKiRShFXwU9grP3 tLv6+1SJ0NJJSQUVKonlwe/d+FEPDITpMeob2Ecc0g== X-Google-Smtp-Source: ADUXVKIisur1YrAfsiHFUG+5OsZKZbBYbJpSEs2uM+Zkv5/IFMPh+z98jfPciR8/oLGvufiE1UQjg4JNiJ60BJY1UeI= X-Received: by 2002:adf:b691:: with SMTP id j17-v6mr451313wre.10.1528942794615; Wed, 13 Jun 2018 19:19:54 -0700 (PDT) MIME-Version: 1.0 References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> In-Reply-To: From: Warren Kumari Date: Wed, 13 Jun 2018 22:19:17 -0400 Message-ID: To: Mark Andrews Cc: David Schinazi , Stuart Cheshire , iana-questions@iana.org, dnsop , IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000027c26e056e90bc08" Archived-At: Subject: Re: [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 02:20:01 -0000 --00000000000027c26e056e90bc08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews wrote: > > > On 13 Jun 2018, at 12:28 pm, David Schinazi wrote= : > > > > Hi everyone, > > > > Stuart and I have a draft that attempts to address these issues, please > let us know if you think it does or doesn't. > > > > https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa > > > > Thanks, > > David Schinazi > > > > This does not meet my requirements. There is zero need for any part of > the normal DNS resolution > process to know the IPV4ONLY.ARPA is special if IANA stopped signing the > zone. That would > allow getaddrinfo() to be able to lookup up the AAAA records without any > intermediate software > having to special case IPV4ONLY.ARPA. IPV4ONLY.ARPA would then validate > as insecure rather > than as secure as it currently does. > =E2=80=8B > I'm not sure that I agree with you on that (let's ignore DNSSEC for now) -- there is little *technical* reason for the normal DNS resolution process to know that ipv4only.arpa is special, but administrators sometimes install ipv4only.arpa resolution locally (for disconnected networks, to improve reliability (e.g when .arpa is slow), or when users are using non-local DNS resolvers (like 8.8.8.8). This is not a technical thing, but rather a blessing that NAT64 / DNS64 admins can do that -- personally this sounds more like an argument for adding it to locally served zones not SUDN. What am I missing here? =E2=80=8B > > The document needs to explicitly state that the delegation for > IPV4ONLY.ARPA in ARPA MUST > be insecure (no DS record). > > RFC7050 Section 7 says: "A signed "ipv4only.arpa." allows validating DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to detect malicious AAAA resource records. Therefore, the zone serving the well-known name has to be protected with DNSSEC." I read that a few times, and even when squinting I cannot figure out how that is supposed to work. Can someone enlighten me? I can see how a signed ipv4only.arpa allows a validating DNS64 server to validate the (well known!) v4 addresses, but the malicious AAAA RR detection bit confuses me..= . > You then have other issues to deal with like not sending queries for > IPV4ONLY.ARPA to servers > which have DNS64 configured or have a local IPV4ONLY.ARPA zone. These ar= e > similar to the issues > for HOME.ARPA but are at the ISP rather than the CPE. > > One way to handle that would be for CPE to always use the DHCP/RA DNS > servers for IPV4ONLY.ARPA > and require a explicit override just for IPV4ONLY.ARPA. > > Another way would be for middle boxes to intercept queries but then you > have to account for > anti spoofing technology TSIG, DNS COOKIE etc. DNS COOKIE just needs the > delegated servers > for IPV4ONLY.ARPA to not serve any other zones. That way any DNS COOKIE > state learnt for the > IP addresses of the servers for IPV4ONLY.ARPA does not impact on > IPV4ONLY.ARPA lookups. > > I mention TSIG because that could be used with a well known TSIG key to > defeat fragmentation > attacks and because TSIG can be used between clients and recursive server= s > that are not > operated by the ISP. This would be one case where DNS resolution softwar= e > may want to be > altered by default. This scenario is even rarer than DNSSEC. > > Mark > =E2=80=8BW =E2=80=8B > > >> On Jun 12, 2018, at 18:29, Mark Andrews wrote: > >> > >> The Domain Name Reservation Considerations in RFC 7050 do not cover > whether > >> a delegation should be signed or not. Due to that omission in > constructing the set > >> of questions to be asked RFC 7050 fails when the client is behind a > validating resolver > >> that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. > >> > >> There are 2 pieces of work that are required. > >> 1) update the list of questions that need to be asked needs to include > whether a delegation > >> needs to be signed or not. > >> 2) update RFC 7050 to include explicit instructions to say DO NOT sign > IPV4ONLY.ARPA. > >> > >> Item 1 is dnsop work as far as I can see. Item 2, I think, should be > v6ops work. > >> > >> HOME.ARPA is a example of a unsigned delegation. > >> 10.IN-ADDR.ARPA is a example of a unsigned delegation. > >> > >> There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on > the Internet > >> are well known. The contents with NAT64 in using are well known excep= t > for the > >> AAAA query. The answer to that query is *expected to change*. That > answer cannot > >> be validated. > >> > >> Mark > >> > >>> Begin forwarded message: > >>> > >>> From: "Michelle Cotton via RT" > >>> Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure= . > >>> Date: 6 January 2018 at 8:45:10 am AEDT > >>> To: marka@isc.org > >>> Reply-To: iana-questions@iana.org > >>> > >>> Hello, > >>> > >>> Following up on a thread from the end of the year. Who will bring > this to the DNSOps working group? Will someone notify us if there is an > consensus on a conclusion of what needs to be done? > >>> > >>> Thanks in advance. > >>> > >>> --Michelle Cotton > >>> > >>> > >>> On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote: > >>>> I had replied to the errata. I agree it warrants additional > >>>> discussion, and had also suggested same. Dnsops seems appropriate. > >>>> > >>>> > >>>> > >>>> The question is not to much where the attacker is, but what DNSSEC > >>>> guarantee is provided. DNS64 imagines the client could do its own > >>>> validation =E2=80=94 if it wanted. To date, effectively zero client= s seem to > >>>> want to do their own DNSSEC validation. > >>>> > >>>> -d > >>>> > >>>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere= ) > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an > >>>>> email address I found from an I-D.. > >>>>> > >>>>> I'm not really following IETF nowadays, so I don't know if this has > >>>>> been discussed. > >>>>> > >>>>> Also I'm not sure why ISPs couldn=E2=80=99t first verify the A resp= onse's > >>>>> validity and then generate AAAA response to the client as document.= .. > >>>>> but I suppose it could be considered to be more proper action to > >>>>> modify insecure responses than secure responses. I'm just worried > >>>>> what happens if there's attacker between ISP and root, in which cas= e > >>>>> the IPv4 address part of the response could be modified by attacker > >>>>> and then delivered to client in the ISP's synthetic AAAA record.. > >>>>> > >>>>> So I cannot accept the errata straight away, but it should be > >>>>> discussed with people who are more experts on this than I am. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Teemu > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Michelle Cotton via RT [mailto:iana-questions- > >>>>> comment@iana.org] > >>>>> Sent: 9. joulukuuta 2017 1:22 > >>>>> Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com; > >>>>> jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere) > >>>>> > >>>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be > >>>>> insecure. > >>>>> > >>>>> Hello, > >>>>> > >>>>> Just checking to see if anyone had a chance to look at this. > >>>>> Dan Wing's email addressed bounced (dwing@cisco.com). > >>>>> > >>>>> Thanks, > >>>>> Michelle > >>>>> > >>>>> > >>>>> > >>>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: > >>>>>> Hello Authors and Area Directors, > >>>>>> > >>>>>> We have received a message pointing out an errata report that woul= d > >>>>>> modify the actions that were performed for RFC7050. > >>>>>> > >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc- > >>>>>> > 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c=3DuilaK90D4TOVoH58JNXRgQ&r=3DIMD= U0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCK= CSggUUCCU7iPuRs- > >>>>>> usGcL3T69Fia9gTOy4UQwhLk&e=3D > >>>>>> > >>>>>> Has this report been discussed? Will the result be an approved > >>>>>> errata > >>>>>> report or a new RFC? > >>>>>> > >>>>>> Thanks in advance. > >>>>>> > >>>>>> Michelle Cotton > >>>>>> Protocol Parameters Engagement Sr. Manager > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000027c26e056e90bc08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tu= e, Jun 12, 2018 at 11:16 PM Mark Andrews <marka@isc.org> wrote:

> On 13 Jun 2018, at 12:28 pm, David Schinazi <dschinazi@apple.com> wrote:
>
> Hi everyone,
>
> Stuart and I have a draft that attempts to address these issues, pleas= e let us know if you think it does or doesn't.
>
> https://tools.ietf.org/html/dr= aft-cheshire-sudn-ipv4only-dot-arpa
>
> Thanks,
> David Schinazi
>

This does not meet my requirements.=C2=A0 There is zero need for any part o= f the normal DNS resolution
process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zo= ne.=C2=A0 That would
allow getaddrinfo() to be able to lookup up the AAAA records without any in= termediate software
having to special case IPV4ONLY.ARPA.=C2=A0 IPV4ONLY.ARPA would then valida= te as insecure rather
than as secure as it currently does.
=E2=80=8B

I'm not sure that = I agree with you on that (let's ignore DNSSEC for now) -- there is litt= le *technical* reason for the normal DNS resolution process to know that ip= v4only.arpa is special, but administrators sometimes install ipv4only.arpa = resolution locally (for disconnected networks, to improve reliability (e.g = when .arpa is slow), or when users are using non-local DNS resolvers (like = 8.8.8.8). This is not a technical thing, but rather a blessing that NAT64 /= DNS64 admins can do that -- personally this sounds more like an argument f= or adding it to locally served zones not SUDN. What am I missing here?

=E2= =80=8B

The document needs to explicitly state that the delegation for IPV4ONLY.ARP= A in ARPA MUST
be insecure (no DS record).


RFC7050 Section 7 says:
"<= /span>A signed "ipv4only.arpa."= ; allows validating
=C2=A0 =C2=A0DNS64 servers (see [RFC6147] Section 3, C= ase 5, for example) to
=C2=A0 =C2=A0detect malicious AAAA resource record= s.=C2=A0 Therefore, the zone serving
=C2=A0 =C2=A0the well-known name has = to be protected with DNSSEC."

I read that a few times, and even= when squinting=C2=A0I cannot figure out how that is supposed to work. Can = someone enlighten me? I can see how a signed ipv4only.arpa allows a validat= ing DNS64 server to validate the (well known!) v4 addresses, but the malici= ous AAAA RR detection bit confuses me...

=C2=A0
You then have other issues to deal with like not sending queries for IPV4ON= LY.ARPA to servers
which have DNS64 configured or have a local IPV4ONLY.ARPA zone.=C2=A0 These= are similar to the issues
for HOME.ARPA but are at the ISP rather than the CPE.

One way to handle that would be for CPE to always use the DHCP/RA DNS serve= rs for IPV4ONLY.ARPA
and require a explicit override just for IPV4ONLY.ARPA.

Another way would be for middle boxes to intercept queries but then you hav= e to account for
anti spoofing technology TSIG, DNS COOKIE etc.=C2=A0 DNS COOKIE just needs = the delegated servers
for IPV4ONLY.ARPA to not serve any other zones.=C2=A0 That way any DNS COOK= IE state learnt for the
IP addresses of the servers for IPV4ONLY.ARPA does not impact on IPV4ONLY.A= RPA lookups.

I mention TSIG because that could be used with a well known TSIG key to def= eat fragmentation
attacks and because TSIG can be used between clients and recursive servers = that are not
operated by the ISP.=C2=A0 This would be one case where DNS resolution soft= ware may want to be
altered by default.=C2=A0 This scenario is even rarer than DNSSEC.

Mark

=E2=80=8BW
=E2=80=8B

>> On Jun 12, 2018, at 18:29, Mark Andrews <marka@isc.org> wrote:
>>
>> The Domain Name Reservation Considerations in RFC 7050 do not cove= r whether
>> a delegation should be signed or not.=C2=A0 Due to that omission i= n constructing the set
>> of questions to be asked RFC 7050 fails when the client is behind = a validating resolver
>> that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA.
>>
>> There are 2 pieces of work that are required.
>> 1) update the list of questions that need to be asked needs to inc= lude whether a delegation
>>=C2=A0 =C2=A0 =C2=A0needs to be signed or not.
>> 2) update RFC 7050 to include explicit instructions to say DO NOT = sign IPV4ONLY.ARPA.
>>
>> Item 1 is dnsop work as far as I can see.=C2=A0 Item 2, I think, s= hould be v6ops work.
>>
>> HOME.ARPA is a example of a unsigned delegation.
>> 10.IN-ADDR.ARPA is a example of a unsigned delegation.
>>
>> There is zero benefit in IPV4ONLY.ARPA being signed.=C2=A0 Its con= tents on the Internet
>> are well known.=C2=A0 The contents with NAT64 in using are well kn= own except for the
>> AAAA query.=C2=A0 The answer to that query is *expected to change*= .=C2=A0 That answer cannot
>> be validated.
>>
>> Mark
>>
>>> Begin forwarded message:
>>>
>>> From: "Michelle Cotton via RT" <iana-questions@iana.org>=
>>> Subject: [IANA #989438] ipv4only.arpa's delegation should = be insecure.
>>> Date: 6 January 2018 at 8:45:10 am AEDT
>>> To: marka@i= sc.org
>>> Reply-To: iana-questions@iana.org
>>>
>>> Hello,
>>>
>>> Following up on a thread from the end of the year.=C2=A0 Who w= ill bring this to the DNSOps working group?=C2=A0 Will someone notify us if= there is an consensus on a conclusion of what needs to be done?
>>>
>>> Thanks in advance.
>>>
>>> --Michelle Cotton
>>>
>>>
>>> On Sun Dec 10 22:40:29 2017, danwing@gmail.com wrote:
>>>> I had replied to the errata. I agree it warrants additiona= l
>>>> discussion, and had also suggested same. Dnsops seems appr= opriate.
>>>>
>>>>
>>>>
>>>> The question is not to much where the attacker is, but wha= t DNSSEC
>>>> guarantee is provided. DNS64 imagines the client could do = its own
>>>> validation =E2=80=94 if it wanted.=C2=A0 To date, effectiv= ely zero clients seem to
>>>> want to do their own DNSSEC validation.
>>>>
>>>> -d
>>>>
>>>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia= -TECH/Tampere)
>>>>> <teemu.savolainen@nokia.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Dan Wing seem to have moved to VMWare, but cc'ing = him now with an
>>>>> email address I found from an I-D..
>>>>>
>>>>> I'm not really following IETF nowadays, so I don&#= 39;t know if this has
>>>>> been discussed.
>>>>>
>>>>> Also I'm not sure why ISPs couldn=E2=80=99t first = verify the A response's
>>>>> validity and then generate AAAA response to the client= as document...
>>>>> but I suppose it could be considered to be more proper= action to
>>>>> modify insecure responses than secure responses. I'= ;m just worried
>>>>> what happens if there's attacker between ISP and r= oot, in which case
>>>>> the IPv4 address part of the response could be modifie= d by attacker
>>>>> and then delivered to client in the ISP's syntheti= c AAAA record..
>>>>>
>>>>> So I cannot accept the errata straight away, but it sh= ould be
>>>>> discussed with people who are more experts on this tha= n I am.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Teemu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Michelle Cotton via RT [mailto:iana-questions-
>>>>> = comment@iana.org]
>>>>> Sent: 9. joulukuuta 2017 1:22
>>>>> Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com;
>>>>> jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere) >>>>> <teemu.savolainen@nokia.com>
>>>>> Subject: [IANA #989438] ipv4only.arpa's delegation= should be
>>>>> insecure.
>>>>>
>>>>> Hello,
>>>>>
>>>>> Just checking to see if anyone had a chance to look at= this.
>>>>> Dan Wing's email addressed bounced (dwing@cisco.com).
>>>>>
>>>>> Thanks,
>>>>> Michelle
>>>>>
>>>>>
>>>>>
>>>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote= :
>>>>>> Hello Authors and Area Directors,
>>>>>>
>>>>>> We have received a message pointing out an errata = report that would
>>>>>> modify the actions that were performed for RFC7050= .
>>>>>>
>>>>>> https://urld= efense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc-
>>>>>> 2Deditor.org_errata_eid5152&d=3DDwIGaQ&c= =3DuilaK90D4TOVoH58JNXRgQ&r=3DIMDU0f3LtPMQf5XkZ06fNg&m=3DhjPiqrkJLc= vBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=3DuCKCSggUUCCU7iPuRs-
>>>>>> usGcL3T69Fia9gTOy4UQwhLk&e=3D
>>>>>>
>>>>>> Has this report been discussed?=C2=A0 Will the res= ult be an approved
>>>>>> errata
>>>>>> report or a new RFC?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Michelle Cotton
>>>>>> Protocol Parameters Engagement Sr. Manager
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 INTERNET: marka@i= sc.org
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >

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


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--00000000000027c26e056e90bc08-- From nobody Wed Jun 13 19:37: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 B149A130DDF for ; Wed, 13 Jun 2018 19:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 bo5a5phGG05h for ; Wed, 13 Jun 2018 19:37:18 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9A312D7F8 for ; Wed, 13 Jun 2018 19:37:18 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id r125-v6so8935076wmg.2 for ; Wed, 13 Jun 2018 19:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+8Ylwo3CAvVP/jmB36tLC8Huu0TI3szyLAYCC2KON8=; b=Pynu1PcyRrjRk/ES7k4STNkhzB/CkImNffN64+vncSyjwKoCvXT9eF0cNt+J8Z1V8l 6vQMSWUXreApbCRvtG4By1OrgaRomeIytTiMw4C37IWeIEJLD+nH6vl9X8KtEioadYMr 5uNjjXhIdpLWWyVFR77qrN6iM4DUCPPzpTTl59kbsVPc8PWdpZ+5ehKbbFFEDIR6Sf05 Brrc7gKIxmGe09pG60Na5qUKTDdA5mNBWTGRZ6fUBuzb6xQhF8A1qILVx1bD2nLnTguR g9DENH6zM1NqfGf362d0kos9iDRsXo8RRlMYwkkHwBtEYK38dxvh3FMF6jVN8P5K4ZZV B7DQ== 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=5+8Ylwo3CAvVP/jmB36tLC8Huu0TI3szyLAYCC2KON8=; b=P3I5Kq+V2CU+49+cXWfTdBDTIDqN7K//ne3dRnxcg8BZ31xGmOwJB65TmVV1se7xJF kl7HxnzMVOMBhdkb2pLyXj6TxxCacLLxvsW2uWw4hKAQDpxHmss3yAS2Eh5FNENuDzlw xopfqo2/QxeNcs/pPX1XYAoy2h090oef8PZEK6gaf55uqCFIFlTdT1nxI+XiWfufjNxg 1msNedOeorn/Kw48YgJeBpgFejXVfA+7SJKb3m6fMk6VWspD5+bSnqe8i9xHaeSwkw5n E6fcotgrm4TG/E+9rzS9jXK1aAUAiohHRw9FFWfK5+bCB+xTE5cI1mRcfAzMJoXUeRmn pFUA== X-Gm-Message-State: APt69E2Fn1ETtRO/LoxqeBUCMnPjO/5Wjhbw3vvmt7gJPmGaK1rhW7Yl avd3VLFp/OUaUQQAZd1o8DAZb0ji68/x5uV/gzIxdw== X-Google-Smtp-Source: ADUXVKJiHCCOJdyXbPL9CmVRCPcbPkquqRpBNrsuJI8K36ZmWH8a9umNDUQTETeCeurqxJ3JKPjWe5TOkNg1rw466pc= X-Received: by 2002:a1c:d2cb:: with SMTP id j194-v6mr288202wmg.129.1528943836636; Wed, 13 Jun 2018 19:37:16 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Thu, 14 Jun 2018 11:37:03 +0900 Message-ID: To: "BARBARA H (ATTLABS) STARK" Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000445124056e90fa22" Archived-At: Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 02:37:21 -0000 --000000000000445124056e90fa22 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H wrote: > The justification presented for the request for a new DHCPv6 option 111 > option code for 464XLAT was that an operator would be running multiple > IPv4aas mechanisms and needed to express which they preferred a CE router > to make use of. The discussion devolved into MAP vs. 464XLAT. The cases > being made for 464XLAT vs MAP seemed to me to make a very strong case > against deploying multiple mechanisms. > > Deploying multiple mechanisms has all the downsides of all the mechanisms. Absolutely. Not just the downsides of all of them, but the cost of implementing all of them, and the increased operational burden of managing all of them at the same time, and the increased operational burden of managing the interaction between multiple mechanisms implemented by the same device. To me, this one positive aspect is such a weak reason, that I would never > use it to justify the additional capex, opex, and customer help desk > costs. +1. --000000000000445124056e90fa22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 14= , 2018 at 10:16 AM STARK, BARBARA H <b= s7652@att.com> wrote:
The ju= stification presented for the request for a new DHCPv6 option 111 option co= de for 464XLAT was that an operator would be running multiple IPv4aas mecha= nisms and needed to express which they preferred a CE router to make use of= . The discussion devolved into MAP vs. 464XLAT. The cases being made for 46= 4XLAT vs MAP seemed to me to make a very strong case against deploying mult= iple mechanisms.

Deploying multiple mechanisms has all the downsides of all the mechanisms. =

Absolutely. Not just the downsides of all = of them, but the cost of implementing all of them, and the increased operat= ional burden of managing all of them at the same time, and the increased op= erational burden of managing the interaction between multiple mechanisms im= plemented by the same device.

To me, this one positive aspect is such a weak reason, that I would n= ever use it to justify the additional capex, opex, and customer help desk c= osts.=C2=A0=C2=A0

+1.=C2=A0
--000000000000445124056e90fa22-- From nobody Wed Jun 13 20:41: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 ABA1912D7F8 for ; Wed, 13 Jun 2018 20:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_p3BCpUvtSc for ; Wed, 13 Jun 2018 20:41:50 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0566C130DC1 for ; Wed, 13 Jun 2018 20:41:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 95DA3B3; Thu, 14 Jun 2018 05:41:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1528947707; bh=AepN35Kvhy/8xmz2s21jHmH+OJZK2mMu/nQhijh7iMk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RHZzh3Q128zsugobWPkM/fcmaPWv47TRdATNDpp4HGnAaRHNJVbBDsBfrpn8pfhkm vIf8aOtbwKpxcOVNHfOGSP+BiL+FsGbAkw0gEEiza/FMZai/7zoZPNoWRv86sc1ZNh SvP2MnHlKvghphkqYHMnmJ8nGWs2s+ECarGx2Zps= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 92D67B2; Thu, 14 Jun 2018 05:41:47 +0200 (CEST) Date: Thu, 14 Jun 2018 05:41:47 +0200 (CEST) From: Mikael Abrahamsson To: "Mudric, Dusan (Dusan)" cc: Richard Patterson , "v6ops@ietf.org list" In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB0867C@AZ-US1EXMB03.global.avaya.com> Message-ID: References: <152879468653.17363.11481811039500870007.idtracker@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459CB08340@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB08439@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459CB0867C@AZ-US1EXMB03.global.avaya.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] New Version Notification for draft-patterson-intarea-ipoe-health-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 03:41:53 -0000 Why would it not check the client identifier? On Wed, 13 Jun 2018, Mudric, Dusan (Dusan) wrote: > I expect the server to deliver the same prefix, if the client is using > PD to create the addresses. But I would not expect the server to offer > the address already in use, unless the server check the client > identifier and is able to figure out which address is used by the > client. > > Dusan > >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >> Sent: Wednesday, June 13, 2018 1:04 AM >> To: Mudric, Dusan (Dusan) >> Cc: Richard Patterson ; v6ops@ietf.org list >> >> Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea- >> ipoe-health-01.txt >> >> On Tue, 12 Jun 2018, Mudric, Dusan (Dusan) wrote: >> >>> lease. Considering the lease will not be RELEASE-d, the server will not >>> offer the lease for the new solicitation. The client should use Server >> >> Hm, I am not an DHCPv6 expert, but in my experience if I power off a >> device with an active lease, power it on again, it comes up again and does >> SOLICIT, it will get the same prefix back that it had before the power >> off (it does not provide any prefix information in the solicit). >> >> What am I missing here? >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jun 13 23:54: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 81EA1130E9F for ; Wed, 13 Jun 2018 23:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evHbpq8jq_BA for ; Wed, 13 Jun 2018 23:54:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5800130DE5 for ; Wed, 13 Jun 2018 23:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528959265; x=1529564065; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=sTFS1Yqg khlaWvNkFiiuVU4qiaclhm62qT/PSLg9PV4=; b=ZP6M+9qqkGbGSGPOwDbkq3iJ fNK4+bpY16VyeihF1kS8Gr+NrgzKAJCGxRxPNkS27XspjFKkgiBvFa7vqC0FG57x qaAjJIzTnaJu8BseN7PjiojgDwSpMNV3P8xkX1JCPmJQlsa1jKvwwcewxIW1IPty sL/ju4VMX9ld9bs9YB8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 08:54:25 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 08:54:24 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789200.msg for ; Thu, 14 Jun 2018 08:54:24 +0200 X-MDRemoteIP: 2001:470:1f09:495:fc18:402c:1782:aeaf X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 08:54:24 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Thu, 14 Jun 2018 08:54:23 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , "v6ops@ietf.org WG" Message-ID: <3259C8C5-B4EF-4EF6-9866-344F014BC62F@consulintel.es> Thread-Topic: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT References: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 06:54:30 -0000 Hi Barbara, This change in our draft was done to respond to your requirement (and also = Richard ones) that an operator moving from "different" scenarios (for examp= le from dual-stack to a "transition-mechanism-1" then to "transition-mechan= ism-2" or to both of them for different customers) has the control over the= CE transition mechanisms, and that can be done not for all the customers, = but in groups or whatever. If all the CE supported transition mechanisms have the same DHCP "way" to b= e prioritized and that can be used to turn each on/off, we satisfy your req= uirement. Otherwise we need to take the decision in the document about how = to prioritize *all* them, which may be good for us, but may be not the corr= ect way for other operators later on. We have not changed the requirements to say that all the mechanisms must be= supported, but if you support them, the logic way to do so is having the 4= 64XLAT option, which is the only one missing (because RFC8026 was develop c= onsidering only the softwires WG mechanisms, and 464XLAT was done in v6ops)= . I still believe that it is a decision of each operator to support one or se= veral transition mechanisms and which ones, but we need to have a CE that c= an accommodate that in a managed way, and that's why RFC8026 was done. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: jueves, 14 de junio de 2018, 3:16 Para: "v6ops@ietf.org WG" Asunto: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to suppo= rt 464XLAT The justification presented for the request for a new DHCPv6 option 111= option code for 464XLAT was that an operator would be running multiple IPv= 4aas mechanisms and needed to express which they preferred a CE router to m= ake use of. The discussion devolved into MAP vs. 464XLAT. The cases being m= ade for 464XLAT vs MAP seemed to me to make a very strong case against depl= oying multiple mechanisms. =20 Deploying multiple mechanisms has all the downsides of all the mechanis= ms. The only positive thing to say is that if the CE router supports one me= chanism, but not the other, then the CE router is still ok. =20 To me, this one positive aspect is such a weak reason, that I would nev= er use it to justify the additional capex, opex, and customer help desk cos= ts.=20 =20 Is there some better justification that I'm missing? If there is no goo= d justification for deploying 464XLAT and MAP-T or MAP-E, then why is a DHC= Pv6 option 111 option code for 464XLAT needed? Barbara =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 14 00:21:39 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 139F4130DF5 for ; Thu, 14 Jun 2018 00:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8wdge-Lwr0DO for ; Thu, 14 Jun 2018 00:21:35 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62941130DE4 for ; Thu, 14 Jun 2018 00:21:35 -0700 (PDT) Received: from [IPv6:2001:738:2c01:22:75d0:c76c:8597:d23e] ([IPv6:2001:738:2c01:22:75d0:c76c:8597:d23e]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5E7LQCB007629 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 14 Jun 2018 09:21:31 +0200 (CEST) (envelope-from lencse@hit.bme.hu) To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Thu, 14 Jun 2018 09:21:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------176F18D9F66A59C90E5BB699" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=2001:738:2c01:22:75d0:c76c:8597:d23e; helo=[IPv6:2001:738:2c01:22:75d0:c76c:8597:d23e]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 Archived-At: Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 07:21:38 -0000 This is a multi-part message in MIME format. --------------176F18D9F66A59C90E5BB699 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I must disagree with this reasoning. First of all, having the option does not mandate any ISP to use multiple transition mechanisms. However, there may be situations, when multiple transition mechanisms are being used. Let me give you just two simple examples. 1. An ISP decides to change from one mechanism to another. (As we have just seen, 464XLAT, MAP-T and MAP-E have different advantages and drawback, thus this can be a rational decision.) The change may last for a while. (E.g. the new subscribers get the new technology and the old subscribers are moved in one year time frame.) Therefore the two mechanisms must coexist in the network of the ISP. 2. An ISP buys up another one and the two networks use two different mechanisms for providing IPv4 as a service. As both infrastructures are ready, it may be a rational decision to keep up both and move some users between them. (E.g. move MAP users, who complained about lack of port situation, to 464XLAT.) So, IMHO, it is useful to have the option to choose among the different mechanisms. Best regard, Gábor Lencse On 6/14/2018 4:37 AM, Lorenzo Colitti wrote: > On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H > wrote: > > The justification presented for the request for a new DHCPv6 > option 111 option code for 464XLAT was that an operator would be > running multiple IPv4aas mechanisms and needed to express which > they preferred a CE router to make use of.. The discussion > devolved into MAP vs. 464XLAT. The cases being made for 464XLAT vs > MAP seemed to me to make a very strong case against deploying > multiple mechanisms. > > Deploying multiple mechanisms has all the downsides of all the > mechanisms. > > > Absolutely. Not just the downsides of all of them, but the cost of > implementing all of them, and the increased operational burden of > managing all of them at the same time, and the increased operational > burden of managing the interaction between multiple mechanisms > implemented by the same device. > > To me, this one positive aspect is such a weak reason, that I > would never use it to justify the additional capex, opex, and > customer help desk costs. > > > +1. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------176F18D9F66A59C90E5BB699 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I must disagree with this reasoning.

First of all, having the option does not mandate any ISP to use multiple transition mechanisms.

However, there may be situations, when multiple transition mechanisms are being used. Let me give you just two simple examples.

1. An ISP decides to change from one mechanism to another. (As we have just seen, 464XLAT, MAP-T and MAP-E have different advantages and drawback, thus this can be a rational decision.) The change may last for a while. (E.g. the new subscribers get the new technology and the old subscribers are moved in one year time frame.) Therefore the two mechanisms must coexist in the network of the ISP.

2. An ISP buys up another one and the two networks use two different mechanisms for providing IPv4 as a service. As both infrastructures are ready, it may be a rational decision to keep up both and move some users between them. (E.g. move MAP users, who complained about lack of port situation, to 464XLAT.)

So, IMHO, it is useful to have the option to choose among the different mechanisms.

Best regard,

Gábor Lencse


On 6/14/2018 4:37 AM, Lorenzo Colitti wrote:
On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H <bs7652@att.com> wrote:
The justification presented for the request for a new DHCPv6 option 111 option code for 464XLAT was that an operator would be running multiple IPv4aas mechanisms and needed to express which they preferred a CE router to make use of.. The discussion devolved into MAP vs. 464XLAT. The cases being made for 464XLAT vs MAP seemed to me to make a very strong case against deploying multiple mechanisms.

Deploying multiple mechanisms has all the downsides of all the mechanisms.

Absolutely. Not just the downsides of all of them, but the cost of implementing all of them, and the increased operational burden of managing all of them at the same time, and the increased operational burden of managing the interaction between multiple mechanisms implemented by the same device.

To me, this one positive aspect is such a weak reason, that I would never use it to justify the additional capex, opex, and customer help desk costs.  

+1. 


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

--------------176F18D9F66A59C90E5BB699-- From nobody Thu Jun 14 00:28: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 6C0CB130DF4 for ; Thu, 14 Jun 2018 00:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqQ01-Z0xPz for ; Thu, 14 Jun 2018 00:28:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202B4130DE4 for ; Thu, 14 Jun 2018 00:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528961325; x=1529566125; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=H8v6xypgJcvzzzyCGM8O4vF5RUllwMCGNb Qx2h6OMN8=; b=NLm9G46issFCVPw79Euqoo5ZjChV63Yc/rTKopOv60ykyNDU6g Jy7kyz9DVoQzGqIBvliWC8K1nKBvPyQ+iw6i9VN4diw1TbQJtgNNnecqqfgwdhx6 fFC043jDTLaY3ob9YkTs8iRnzhIuvHCP1pG4Ac9DvQHTjU97g7FAlXFZo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 09:28:45 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 09:28:44 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789215.msg for ; Thu, 14 Jun 2018 09:28:44 +0200 X-MDRemoteIP: 2001:470:1f09:495:fc18:402c:1782:aeaf X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 09:28:44 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Thu, 14 Jun 2018 09:28:41 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: <6D9E0ECD-F2C7-4352-A77C-42D291ED4C53@consulintel.es> Thread-Topic: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT References: <2D09D61DDFA73D4C884805CC7865E6114DDEB318@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611813321_1637278831" Archived-At: Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 07:28:51 -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_3611813321_1637278831 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable There may be one *very common* more reason as well. =20 The ISP has a group of customers with CEs that only support one mechanism, = which is different to the (actually) preferred transition mechanism, and th= e ISP don=E2=80=99t want to replace those CEs, or not immediately. =20 This was the main rational used in RFC8026: =20 =E2=80=9CA common feature shared among all of the differing modes is the =C2=A0=C2=A0 integration of softwire tunnel endpoint functionality into the =C2=A0=C2=A0 Customer Premises Equipment (CPE) router.=C2=A0 Due to this in= herent data =C2=A0=C2=A0 plane similarity, a single CPE may be capable of supporting se= veral =C2=A0=C2=A0 different approaches.=C2=A0 Users may also wish to configure a= specific =C2=A0=C2=A0 mode of operation. =20 =C2=A0=C2=A0 A service provider's network may also have more than one S46 =C2=A0=C2=A0 mechanism enabled in order to support a diverse CPE population= with =C2=A0=C2=A0 differing client functionality, such as during a migration bet= ween =C2=A0=C2=A0 mechanisms or where services require specific supporting softw= ire =C2=A0=C2=A0 architectures.=E2=80=9D Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: jueves, 14 de junio de 2018, 9:22 Para: Asunto: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to suppo= rt 464XLAT =20 I must disagree with this reasoning. First of all, having the option does not mandate any ISP to use multiple tr= ansition mechanisms. However, there may be situations, when multiple transition mechanisms are b= eing used. Let me give you just two simple examples. 1. An ISP decides to change from one mechanism to another. (As we have just= seen, 464XLAT, MAP-T and MAP-E have different advantages and drawback, thu= s this can be a rational decision.) The change may last for a while. (E.g. = the new subscribers get the new technology and the old subscribers are move= d in one year time frame.) Therefore the two mechanisms must coexist in the= network of the ISP. 2. An ISP buys up another one and the two networks use two different mechan= isms for providing IPv4 as a service. As both infrastructures are ready, it= may be a rational decision to keep up both and move some users between the= m. (E.g. move MAP users, who complained about lack of port situation, to 46= 4XLAT.) So, IMHO, it is useful to have the option to choose among the different mec= hanisms. Best regard, G=C3=A1bor Lencse =20 On 6/14/2018 4:37 AM, Lorenzo Colitti wrote: On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H wrote: The justification presented for the request for a new DHCPv6 option 111 opt= ion code for 464XLAT was that an operator would be running multiple IPv4aas= mechanisms and needed to express which they preferred a CE router to make = use of.. The discussion devolved into MAP vs. 464XLAT. The cases being made= for 464XLAT vs MAP seemed to me to make a very strong case against deployi= ng multiple mechanisms. Deploying multiple mechanisms has all the downsides of all the mechanisms.= =20 =20 Absolutely. Not just the downsides of all of them, but the cost of implemen= ting all of them, and the increased operational burden of managing all of t= hem at the same time, and the increased operational burden of managing the = interaction between multiple mechanisms implemented by the same device. =20 To me, this one positive aspect is such a weak reason, that I would never u= se it to justify the additional capex, opex, and customer help desk costs. = =20 =20 +1.=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611813321_1637278831 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

There may be one *very common* more reason as well.

 

The ISP has a group of c= ustomers with CEs that only support one mechanism, which is different to th= e (actually) preferred transition mechanism, and the ISP don=E2=80=99t want= to replace those CEs, or not immediately.

&nbs= p;

This was the main rational used in RFC8026:=

 

=E2=80=9CA common feature sh=
ared among all of the differing modes is the

=C2=A0= =C2=A0 integration of softwire tunnel endpoint functionality into the<= /o:p>

=C2=A0=C2=A0 plane similari= ty, a single CPE may be capable of supporting several

=

= =C2=A0=C2=A0 different approaches.=C2=A0 Users may also wish to configure a= specific

=C2=A0=C2=A0 mode of operation.

 

=C2=A0=C2=A0 A service provider's network= may also have more than one S46

=C2=A0=C2=A0 mechanism= enabled in order to support a diverse CPE population with

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"PT Mono";color:bla= ck'>=C2=A0=C2=A0 differing client functionality, such as during a migration= between

=C2=A0=C2=A0 mechanisms or where services requ= ire specific supporting softwire

=C2=A0=C2=A0 architectu= res.=E2=80= =9D
Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse G=C3=A1b= or <lencse@hit.bme.hu>
Fecha: jueves, 14 de junio de 2018, = 9:22
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] M= AP vs 464XLAT and request to updating RFC8026 to support 464XLAT=

 

I must disagree wit= h this reasoning.

First of al= l, having the option does not mandate any ISP to use multiple transition me= chanisms.

However, there may = be situations, when multiple transition mechanisms are being used. Let me g= ive you just two simple examples.

1. An ISP decides to change from one mechanism to another. (As we have= just seen, 464XLAT, MAP-T and MAP-E have different advantages and drawback= , thus this can be a rational decision.) The change may last for a while. (= E.g. the new subscribers get the new technology and the old subscribers are= moved in one year time frame.) Therefore the two mechanisms must coexist i= n the network of the ISP.

2. = An ISP buys up another one and the two networks use two different mechanism= s for providing IPv4 as a service. As both infrastructures are ready, it ma= y be a rational decision to keep up both and move some users between them. = (E.g. move MAP users, who complained about lack of port situation, to 464XL= AT.)

So, IMHO, it is useful t= o have the option to choose among the different mechanisms.

<= p style=3D'margin-left:35.4pt'>Best regard,

G=C3=A1bor Lencse

 

On 6/14/2018 4:37 AM, Lorenzo Colitti wrote:<= /o:p>

<= div>

On Thu, Jun= 14, 2018 at 10:16 AM STARK, BARBARA H <bs7652@att.com> wrote:

The justification presented for the request for a new DHCPv6 option 111= option code for 464XLAT was that an operator would be running multiple IPv= 4aas mechanisms and needed to express which they preferred a CE router to m= ake use of.. The discussion devolved into MAP vs. 464XLAT. The cases being = made for 464XLAT vs MAP seemed to me to make a very strong case against dep= loying multiple mechanisms.

Deploying multiple mechanisms has all th= e downsides of all the mechanisms.

 

=

Absolutely. Not just the = downsides of all of them, but the cost of implementing all of them, and the= increased operational burden of managing all of them at the same time, and= the increased operational burden of managing the interaction between multi= ple mechanisms implemented by the same device.

 

To me, this one positive aspect i= s such a weak reason, that I would never use it to justify the additional c= apex, opex, and customer help desk costs.  

 

+1.&nbs= p;




____=
___________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops<=
/o:p>

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

=
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611813321_1637278831-- From nobody Thu Jun 14 02:32: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 A97CD130F2F for ; Thu, 14 Jun 2018 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 MkcNPrsGEC2b for ; Thu, 14 Jun 2018 02:32:34 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CB4130E16 for ; Thu, 14 Jun 2018 02:32:33 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v16-v6so9347597wmh.5 for ; Thu, 14 Jun 2018 02:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a1yUH769Sj89Vb4rbIjtWTBduUBeBbljHGCojLRvgRE=; b=slDFjc7hnPChqNcXJj5NKe4d+5IoTIbEI4mXDmUiR5ZZ0dAzYM0T2ATHYFdJhm67sq iZx6AFabrXwR/W3inhkXW47dym1V6TQ+jQglRvosZL+nDe1z+xCX4lZoLMGYNsElDR2Q uYg5bIdGopopWntUKgjkYeCHKU6Buh5M8gmBMXHqHqZ4ZhX95WQ2yO/J2Dir0Yk5bUlh MildPz++9ipHB7waNkIKUdd6wrRynqOzTxX4A7qwYDtRTzNchOHDlyDNElftG9F7ohKt ek70ptXL7IOSmIqVca2+nJfzQoE9MmCUWODe9A8J1JWSTGqUczwTrP/AGrp3QwfnmNox VzFQ== 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=a1yUH769Sj89Vb4rbIjtWTBduUBeBbljHGCojLRvgRE=; b=YUdj3BwfFKW/JV7K7l9ubpyDAP6p4YapNQUGXqE7sMyPBHWSngxSr7VFluG1NmkT2U P+OhsEhooXtDuCeBDMIjPDMEbMFEcFvGQTHQMXXSkc6pK4oBvo/qYskcqhrxODECe/YL 2oOhE2lZyXtBatEVtsw1S2TOJgGawwjr+q0p/xz7Xv4a9Ak01JRqucT39Zg+mJ7MM5sr /72jFhrR/y+qaPvtZZzDRjrB/iMbnoYfBV2Q93U0G51riGpFGVkZ4/tjhBJoFGTnC4iv 4DEezaZGeRND9RMeUNO940ZABb8EzO/STzPw3IFfox2V9kMLxbrL9WJOEhkYyVAt7Cog zcVA== X-Gm-Message-State: APt69E1ujydau4X7y1d9UrpaeEHDK5Mpu2sT+i4RT9fYUflH3IIchSCa DS3RpIS8dga/gf1+FSbJlOhVF1aLErFvCFc9yZKmxQ== X-Google-Smtp-Source: ADUXVKIEwjJFTPfPCiaZENLd/b+c6eb5iumBugMN0LCIodEnFLWgiF+i7Zt1ubCAhtQDItrrZm4CXuSTkxMaFN45DEw= X-Received: by 2002:a1c:8312:: with SMTP id f18-v6mr1262178wmd.127.1528968751969; Thu, 14 Jun 2018 02:32:31 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> In-Reply-To: <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> From: Lorenzo Colitti Date: Thu, 14 Jun 2018 18:32:20 +0900 Message-ID: To: Ole Troan Cc: lencse@hit.bme.hu, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000561925056e96c773" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 09:32:36 -0000 --000000000000561925056e96c773 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 4:37 AM Ole Troan wrote: > The main "benefit" of 464XLAT is two-fold. It was lighter on provisioning > than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which could > serve IPv6 only hosts reaching the IPv4 Internet. > Almost. The "benefits" that led to 464xlat being widely deployed were: - It didn't use encapsulation, so it didn't break the DPI / header enrichment / billing / QoS ... systems used by mobile networks. - It didn't use DHCPv6 so it was possible to provision it on networks that don't support DHCPv6, like mobile networks. The first implementation used ipv4.google.com. - There were already NAT64s in the field because people had tried to deploy IPv6-only with NAT64 and failed due to app breakage. --000000000000561925056e96c773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 14= , 2018 at 4:37 AM Ole Troan <otr= oan@employees.org> wrote:
Th= e main "benefit" of 464XLAT is two-fold. It was lighter on provis= ioning than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which = could serve IPv6 only hosts reaching the IPv4 Internet.
=C2=A0
Almost. The "benefits" that led to 464xlat bei= ng widely deployed were:
  • It didn't use encapsulation,= so it didn't break the DPI / header enrichment / billing / QoS ... sys= tems used by mobile networks.
  • It didn't use DHCPv6 so it was po= ssible to provision it on networks that don't support DHCPv6, like mobi= le networks. The first implementation used ipv4.google.com.
  • There were already NAT64s in the field beca= use people had tried to deploy IPv6-only with NAT64 and failed due to app b= reakage.
--000000000000561925056e96c773-- From nobody Thu Jun 14 03:28: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 2BDA4130EBE for ; Thu, 14 Jun 2018 03:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zi6pt4vYMzcZ for ; Thu, 14 Jun 2018 03:28:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95464130F00 for ; Thu, 14 Jun 2018 03:28:17 -0700 (PDT) Received: from tpw09926dag09f.domain1.systemhost.net (10.9.202.40) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 11:28:16 +0100 Received: from tpw09926dag17f.domain1.systemhost.net (10.9.212.25) by tpw09926dag09f.domain1.systemhost.net (10.9.202.40) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 14 Jun 2018 11:28:12 +0100 Received: from RDW083A007ED63.bt.com (10.187.98.12) by tpw09926dag17f.domain1.systemhost.net (10.9.212.25) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Thu, 14 Jun 2018 11:28:12 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (23.103.134.144) by smtpe1.intersmtp.com (62.239.224.236) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 11:28:36 +0100 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:X-MS-Exchange-SenderADCheck; bh=uuPzrkapyaG1dp7M5AEX+ACoQkwqhm1E4pb6WzOZUMM=; b=k7l7dU2K2CPW9l/7U22+a8rILy+3uCXhrUtvdZK1mVh0pfkLV9WAVyR9oF9tIMPpKQbwhSD0A7n6drNRVv2eIFOHK7ihuzkbj0iUP8/QkotwixWSRhYO3zO2QYFy0eRIj0Ied/jMuFo6G1BI3FEbEUQJiWzcymgqiH00b2WiXrA= Received: from LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM (10.167.24.141) by LO1P123MB0804.GBRP123.PROD.OUTLOOK.COM (10.167.25.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Thu, 14 Jun 2018 10:28:05 +0000 Received: from LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM ([fe80::447b:b457:ce32:4a88]) by LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM ([fe80::447b:b457:ce32:4a88%7]) with mapi id 15.20.0863.016; Thu, 14 Jun 2018 10:28:05 +0000 From: To: , CC: Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUA8LDRjDhXVibNU6g9q4o+7Bxy6RfgS2A Date: Thu, 14 Jun 2018 10:28:05 +0000 Message-ID: References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> 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; LO1P123MB0804; 7:hTmv9sbKMBe/XoJT540G0AqBv25kgQ6a19PI4zisC9nB8wSiA6WJVBEMWValNicNdDMpQwmjFSu8v7aaYJ5NyoLL0k19qitXTR5qdDGvUBwJVjyJ6irq7cPPveLFJdEIV1FWee4tis7FyBVf44jeFUJxO2NmKqocwO9hsgFpxivJxlI6n5tyQKfSkRkxIszD+wb5KwCT56YWKogj2qiP0loNRO6stbF6aDtA+LrqwOOTWgtStFTe8QrJLmvR6Ypx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 997c5cd7-d1fb-40cd-4e39-08d5d1e1840b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:LO1P123MB0804; x-ms-traffictypediagnostic: LO1P123MB0804: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(211936372134217)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:LO1P123MB0804; BCL:0; PCL:0; RULEID:; SRVR:LO1P123MB0804; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(376002)(396003)(346002)(366004)(189003)(199004)(53386004)(606006)(105586002)(2906002)(446003)(86362001)(106356001)(790700001)(316002)(5250100002)(25786009)(5660300001)(11346002)(486006)(3280700002)(229853002)(6116002)(478600001)(4326008)(3660700001)(476003)(1680700002)(3846002)(66066001)(33656002)(6246003)(99286004)(74316002)(7736002)(55016002)(53936002)(9686003)(6436002)(186003)(14454004)(8676002)(68736007)(93886005)(8936002)(102836004)(97736004)(81166006)(81156014)(6306002)(236005)(76176011)(26005)(54896002)(110136005)(2900100001)(6506007)(53546011)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0804; H:LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lHupk3OKSltujsG4LUyGT7o/FTCJwSYJ/ss4XkhTa8CDRVsgvwqjwYo1MSCCOQ9xLb/OLXhObHQE+3PRVaHbF8ZCUlyhAFlHa7bqSvtB2gctyb16iaU5DM6/LHEtd851isEeAlQkYiVRLTLc2hMZF2vZtxrrLgc86lmwTS/uAGOLmPXKA0D9xUfHbSSUSdac spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB009872BA45A52D18819FF3A6EA7D0LO1P123MB0098GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 997c5cd7-d1fb-40cd-4e39-08d5d1e1840b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 10:28:05.4752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0804 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 10:28:22 -0000 --_000_LO1P123MB009872BA45A52D18819FF3A6EA7D0LO1P123MB0098GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhwYW5kaW5nIG9uIHlvdXIgbGFzdCBwb2ludDoNCj4gVGhlcmUgd2VyZSBhbHJlYWR5IE5BVDY0 cyBpbiB0aGUgZmllbGQgYmVjYXVzZSBwZW9wbGUgaGFkIHRyaWVkIHRvIGRlcGxveSBJUHY2LW9u bHkgd2l0aCBOQVQ2NCBhbmQgZmFpbGVkIGR1ZSB0byBhcHAgYnJlYWthZ2UuDQpUaGVyZSB3ZXJl IG5vIE5BVDY0cyBpbiBwcm9kdWN0aW9uIGZvciBwYXlpbmcgY3VzdG9tZXJzLCBvbmx5IE5BVDQ0 LCBhcyB5b3Ugc2F5LCBhcHBzIHdlcmUgYnJlYWtpbmcuDQpNb2JpbGUgT3BlcmF0b3JzIHdlcmUg YWxyZWFkeSB1c2luZyBOQVQ0NCwgdG8gZGVmZW5kIGFnYWluc3QgSVB2NCBwdWJsaWMgZXhoYXVz dGlvbi4NClNvbWUgTW9iaWxlIE9wZXJhdG9ycyB3ZXJlIGNvbmNlcm5lZCB3aXRoIHByaXZhdGUg YWRkcmVzcyBleGhhdXN0aW9uICgyME0gcHJpdmF0ZSBJUHMgaXMgbm90IGVub3VnaCkuDQoNCldp dGggTkFUNDQgYWxsIHRyYWZmaWMgcGFzc2VzIHZpYSBDR04uDQpXaXRoIE5BVDY0IGFuZCA0NjR4 bGF0IHRoZW4gSVB2NiBpcyBub3QgdHJhbnNsYXRlZCBhbmQgb25seSB0aGUgdjQtb25seSBkZXN0 aW5hdGlvbnMgZ28gdmlhIE5BVDY0Lg0KTGVzcyBDR04gYnVyZGVuLCBhbmQgSVB2NiBlbmFibGVk Lg0KUHJpdmF0ZSBJUCBleGhhdXN0aW9uIGlzIG1pdGlnYXRlZC4gUHJpdmF0ZSBJUCBleGhhdXN0 aW9uIHRlbmRzIHRvIGdldCBmb3Jnb3R0ZW4gYnV0IHRoaXMgaXMgY3JpdGljYWxseSB3aHkgTkFU NDQgbWF5IGhhdmUgbGltaXRlZCBsaWZlIChmb3IgSVNQcyB3aXRoIGxhcmdlciBiYXNlcykuDQoN CklmIHRoZSByZXF1aXJlbWVudCBpcyBkbyBzb21ldGhpbmcgYmV0dGVyIHRoYW4gTkFUNDQgQ0dO IHRoZW4geW91IGNhbiBzZWUgd2h5IDQ2NHhsYXQgaGFzIGl0cyBwbGFjZS4NCk1BUC1UIGNvdWxk IGluIHRoZW9yeSBkbyB0aGlzIGpvYi4gaXQgc2VlbXMgbW9yZSBjb21wbGV4IHRvIGRlcGxveSBh bmQgdGhlIGNhc2UgdG8gZ28gZnJvbSA0NjR4bGF0IHRvIE1BUC1UIHNlZW1zIHdlYWssIGJ1dCBp ZiBpdCByZWFsbHkgZXhpc3RlZCBpbiBtb2JpbGUgZGV2aWNlcyBpdCBtYXkgYmUgc29tZXRoaW5n IHRvIGNvbnNpZGVyLg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IDE0IEp1bmUgMjAxOCAxMDoz Mg0KVG86IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+DQpDYzogdjZvcHNAaWV0Zi5v cmcgV0cgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gRGlzYWR2YW50YWdl cyBvZiBNQVAgcHJvdG9jb2xzIC0tIFJlOiBJcyA0NjRYTEFUIHJlYWxseSBpbmZlcmlvciB0byBh bGwgb3RoZXIgSVB2NiB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcz8gLS0gUmU6IHVwZGF0aW5nIFJG QzgwMjYgdG8gc3VwcG9ydCA0NjRYTEFUIGluIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1p cHY0YWFzDQoNCk9uIFRodSwgSnVuIDE0LCAyMDE4IGF0IDQ6MzcgQU0gT2xlIFRyb2FuIDxvdHJv YW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc+PiB3cm90ZToNClRo ZSBtYWluICJiZW5lZml0IiBvZiA0NjRYTEFUIGlzIHR3by1mb2xkLiBJdCB3YXMgbGlnaHRlciBv biBwcm92aXNpb25pbmcgdGhhbiBlLmcuIE1BUC1FIG9yIE1BUC1UIGFuZCBpdCBjb3VsZCByZXVz ZSBhIHN0YXRlZnVsIE5BVDY0LCB3aGljaCBjb3VsZCBzZXJ2ZSBJUHY2IG9ubHkgaG9zdHMgcmVh Y2hpbmcgdGhlIElQdjQgSW50ZXJuZXQuDQoNCkFsbW9zdC4gVGhlICJiZW5lZml0cyIgdGhhdCBs ZWQgdG8gNDY0eGxhdCBiZWluZyB3aWRlbHkgZGVwbG95ZWQgd2VyZToNCg0KICAqICAgSXQgZGlk bid0IHVzZSBlbmNhcHN1bGF0aW9uLCBzbyBpdCBkaWRuJ3QgYnJlYWsgdGhlIERQSSAvIGhlYWRl ciBlbnJpY2htZW50IC8gYmlsbGluZyAvIFFvUyAuLi4gc3lzdGVtcyB1c2VkIGJ5IG1vYmlsZSBu ZXR3b3Jrcy4NCiAgKiAgIEl0IGRpZG4ndCB1c2UgREhDUHY2IHNvIGl0IHdhcyBwb3NzaWJsZSB0 byBwcm92aXNpb24gaXQgb24gbmV0d29ya3MgdGhhdCBkb24ndCBzdXBwb3J0IERIQ1B2NiwgbGlr ZSBtb2JpbGUgbmV0d29ya3MuIFRoZSBmaXJzdCBpbXBsZW1lbnRhdGlvbiB1c2VkIGlwdjQuZ29v Z2xlLmNvbTxodHRwOi8vaXB2NC5nb29nbGUuY29tPi4NCiAgKiAgIFRoZXJlIHdlcmUgYWxyZWFk eSBOQVQ2NHMgaW4gdGhlIGZpZWxkIGJlY2F1c2UgcGVvcGxlIGhhZCB0cmllZCB0byBkZXBsb3kg SVB2Ni1vbmx5IHdpdGggTkFUNjQgYW5kIGZhaWxlZCBkdWUgdG8gYXBwIGJyZWFrYWdlLg0K --_000_LO1P123MB009872BA45A52D18819FF3A6EA7D0LO1P123MB0098GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEzMDA0OTc1MDA7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00MDc0MTEzNjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5FeHBhbmRpbmcgb24geW91ciBsYXN0IHBvaW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7PC9zcGFuPiBUaGVyZSB3ZXJlIGFscmVhZHkg TkFUNjRzIGluIHRoZSBmaWVsZCBiZWNhdXNlIHBlb3BsZSBoYWQgdHJpZWQgdG8gZGVwbG95IElQ djYtb25seSB3aXRoIE5BVDY0IGFuZCBmYWlsZWQgZHVlIHRvIGFwcCBicmVha2FnZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhlcmUgd2VyZSBubyBOQVQ2NHMgaW4gcHJvZHVjdGlvbiBmb3IgcGF5 aW5nIGN1c3RvbWVycywgb25seSBOQVQ0NCwgYXMgeW91IHNheSwgYXBwcyB3ZXJlIGJyZWFraW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TW9iaWxlIE9wZXJhdG9ycyB3ZXJlIGFscmVh ZHkgdXNpbmcgTkFUNDQsIHRvIGRlZmVuZCBhZ2FpbnN0IElQdjQgcHVibGljIGV4aGF1c3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Tb21lIE1vYmlsZSBPcGVyYXRvcnMgd2VyZSBj b25jZXJuZWQgd2l0aCBwcml2YXRlIGFkZHJlc3MgZXhoYXVzdGlvbiAoMjBNIHByaXZhdGUgSVBz IGlzIG5vdCBlbm91Z2gpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaXRoIE5BVDQ0IGFsbCB0cmFmZmljIHBhc3NlcyB2aWEg Q0dOLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2l0aCBOQVQ2NCBhbmQgNDY0eGxhdCB0 aGVuIElQdjYgaXMgbm90IHRyYW5zbGF0ZWQgYW5kIG9ubHkgdGhlIHY0LW9ubHkgZGVzdGluYXRp b25zIGdvIHZpYSBOQVQ2NC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TGVzcyBDR04g YnVyZGVuLCBhbmQgSVB2NiBlbmFibGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UHJp dmF0ZSBJUCBleGhhdXN0aW9uIGlzIG1pdGlnYXRlZC4gUHJpdmF0ZSBJUCBleGhhdXN0aW9uIHRl bmRzIHRvIGdldCBmb3Jnb3R0ZW4gYnV0IHRoaXMgaXMgY3JpdGljYWxseSB3aHkgTkFUNDQgbWF5 IGhhdmUgbGltaXRlZCBsaWZlIChmb3IgSVNQcyB3aXRoIGxhcmdlciBiYXNlcykuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklm IHRoZSByZXF1aXJlbWVudCBpcyBkbyBzb21ldGhpbmcgYmV0dGVyIHRoYW4gTkFUNDQgQ0dOIHRo ZW4geW91IGNhbiBzZWUgd2h5IDQ2NHhsYXQgaGFzIGl0cyBwbGFjZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPk1BUC1UIGNvdWxkIGluIHRoZW9yeSBkbyB0aGlzIGpvYi4gaXQgc2VlbXMg bW9yZSBjb21wbGV4IHRvIGRlcGxveSBhbmQgdGhlIGNhc2UgdG8gZ28gZnJvbSA0NjR4bGF0IHRv IE1BUC1UIHNlZW1zIHdlYWssIGJ1dCBpZiBpdCByZWFsbHkgZXhpc3RlZCBpbiBtb2JpbGUgZGV2 aWNlcyBpdCBtYXkgYmUgc29tZXRoaW5nIHRvIGNvbnNpZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IDE0IEp1bmUgMjAxOCAxMDoz Mjxicj4NCjxiPlRvOjwvYj4gT2xlIFRyb2FuICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs8 YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnIFdHICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gRGlzYWR2YW50YWdlcyBvZiBNQVAgcHJv dG9jb2xzIC0tIFJlOiBJcyA0NjRYTEFUIHJlYWxseSBpbmZlcmlvciB0byBhbGwgb3RoZXIgSVB2 NiB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcz8gLS0gUmU6IHVwZGF0aW5nIFJGQzgwMjYgdG8gc3Vw cG9ydCA0NjRYTEFUIGluIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1 biAxNCwgMjAxOCBhdCA0OjM3IEFNIE9sZSBUcm9hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm90cm9h bkBlbXBsb3llZXMub3JnIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IG1haW4gJnF1b3Q7YmVuZWZpdCZxdW90OyBvZiA0NjRYTEFUIGlzIHR3by1mb2xkLiBJdCB3YXMg bGlnaHRlciBvbiBwcm92aXNpb25pbmcgdGhhbiBlLmcuIE1BUC1FIG9yIE1BUC1UIGFuZCBpdCBj b3VsZCByZXVzZSBhIHN0YXRlZnVsIE5BVDY0LCB3aGljaCBjb3VsZCBzZXJ2ZSBJUHY2IG9ubHkg aG9zdHMgcmVhY2hpbmcgdGhlIElQdjQgSW50ZXJuZXQuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbG1vc3QuIFRoZSAmcXVvdDti ZW5lZml0cyZxdW90OyB0aGF0IGxlZCB0byA0NjR4bGF0IGJlaW5nIHdpZGVseSBkZXBsb3llZCB3 ZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KSXQgZGlkbid0IHVzZSBlbmNhcHN1bGF0aW9uLCBzbyBpdCBkaWRuJ3QgYnJlYWsgdGhl IERQSSAvIGhlYWRlciBlbnJpY2htZW50IC8gYmlsbGluZyAvIFFvUyAuLi4gc3lzdGVtcyB1c2Vk IGJ5IG1vYmlsZSBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgZGlkbid0IHVz ZSBESENQdjYgc28gaXQgd2FzIHBvc3NpYmxlIHRvIHByb3Zpc2lvbiBpdCBvbiBuZXR3b3JrcyB0 aGF0IGRvbid0IHN1cHBvcnQgREhDUHY2LCBsaWtlIG1vYmlsZSBuZXR3b3Jrcy4gVGhlIGZpcnN0 IGltcGxlbWVudGF0aW9uIHVzZWQNCjxhIGhyZWY9Imh0dHA6Ly9pcHY0Lmdvb2dsZS5jb20iPmlw djQuZ29vZ2xlLmNvbTwvYT4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZXJlIHdlcmUgYWxy ZWFkeSBOQVQ2NHMgaW4gdGhlIGZpZWxkIGJlY2F1c2UgcGVvcGxlIGhhZCB0cmllZCB0byBkZXBs b3kgSVB2Ni1vbmx5IHdpdGggTkFUNjQgYW5kIGZhaWxlZCBkdWUgdG8gYXBwIGJyZWFrYWdlLjxv OnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_LO1P123MB009872BA45A52D18819FF3A6EA7D0LO1P123MB0098GBRP_-- From nobody Thu Jun 14 03:31:09 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 1D4E7130F0B for ; Thu, 14 Jun 2018 03:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 yDQ698G-zh7F for ; Thu, 14 Jun 2018 03:31:06 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CFF130F09 for ; Thu, 14 Jun 2018 03:31:02 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id f16-v6so5862161wrm.3 for ; Thu, 14 Jun 2018 03:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dxMqO5zNTPXvNtMWLc8898kJCJWQrwNilStc3/ON2eQ=; b=GMuPt5BlJKmV9MZpfzMh1GrpplmHkEOuVy9k9q9RgwBnD4naXp1LnPya7ODJx4eyOR +6/mFQULJ3juGB6+PTv5fvpz+/4zOwDAE1wMi1ZkgcKSYjkvSWa50fI79vk8CxSKg8Hk AfZYJg6jqrbFAbTCROpqyrxiUjImDfBsVtNuGwP+FZ2WXybkD8d1kDHAjYK/016fngNI ysP49a6LO2OJ8tdKHuyYH+uaBK/o0bsClUPG/XHm2H+6E1K+eV/qGY0YKRBofVApeEIn p4SR/TMocARPokSM2h6OZW7BP+dAJvzSOMhg/YWwrgxnNUIC2oOP2iI2XiTZcCg4jK0f RPCw== 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=dxMqO5zNTPXvNtMWLc8898kJCJWQrwNilStc3/ON2eQ=; b=C8ZIe0TJ5lK0TC5m3I3B4kLWSlqcaT/T31PKt3KY+0QiCmPB0tCzhWU4VItOYgAIcS hIGhyMqN/TnA3nPQg+s2aXp8Nuh0+LaqOugEHnH3NzI9+KI+lMhp6l57A5lVjvQLBs58 4G8dCcgFP4KzR1KqedriT4EzSFqPjEwCYO+HLi3J523wPk6yCIHhGb+kMl8Nq/vjdOSp nQhcYqW5nY6AGuKk3DrQafYnQLbjGP0NapHg9CK9JI9FEcX9xFpLLonoIaMDkP7FEYLU SmiIFfqtchMJJcck0SKYw2LaqSPVSc554jvgr6iULp11BrstmWREBo8vqtwPincfHUed ZlnQ== X-Gm-Message-State: APt69E2heM3SEsE1vzsOmtkn1Yg/uAXH75uwVnYWn+4u0j6Jhc4JmalA uWPKbLaFhsGoj9vtoBnnLAT3IddiRXwoezYIJIhcOA== X-Google-Smtp-Source: ADUXVKIms9e/GOTfNd09yKdhGUaAqTVhCQvTBrKYD2E6ITFWx/Num9wlMNWpSJDvDLwJRHykx8AQp557IdA856Iwdh4= X-Received: by 2002:adf:e392:: with SMTP id e18-v6mr1784376wrm.94.1528972260306; Thu, 14 Jun 2018 03:31:00 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> In-Reply-To: From: Lorenzo Colitti Date: Thu, 14 Jun 2018 19:30:46 +0900 Message-ID: To: "Heatley,N,Nick,TQB R" Cc: Ole Troan , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000731820056e9798c0" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 10:31:08 -0000 --000000000000731820056e9798c0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 7:28 PM wrote: > If the requirement is do something better than NAT44 CGN then you can see > why 464xlat has its place. > > MAP-T could in theory do this job. it seems more complex to deploy and the > case to go from 464xlat to MAP-T seems weak, but if it really existed in > mobile devices it may be something to consider. > Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-) I'm just saying it's not the best solution for a wireline network. --000000000000731820056e9798c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 14= , 2018 at 7:28 PM <nick.heatley@b= t.com> wrote:

If the requirement is do something better than NAT44= CGN then you can see why 464xlat has its place.

MAP-T could in theory do this job. it seems mo= re complex to deploy and the case to go from 464xlat to MAP-T seems weak, b= ut if it really existed in mobile devices it may be something to consider.<= /span>


Oh, I definitely agr= ee that 464xlat has it's place. I maintain a popular implementation of = it :-)

I'm just saying it's not the best s= olution for a wireline network.=C2=A0
--000000000000731820056e9798c0-- From nobody Thu Jun 14 05:12: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 E074A13113A for ; Thu, 14 Jun 2018 05:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78yzRWyg_nbY for ; Thu, 14 Jun 2018 05:12:49 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B791292F1 for ; Thu, 14 Jun 2018 05:12:49 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id v197-v6so2035275ywc.13 for ; Thu, 14 Jun 2018 05:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s0Ak/xNC1dXDei9cjDRs41ZWc7vt5UFYJiQ0a6aU4Ys=; b=s7ZlbmTjmAlE1EfAEkVJ6Nexp8+WS2WEbVGsI49kPvh3dVkuccPyJRhpVQ3BJ+vC/H pdFWNqnkvchHnx3Qh0Od0mkIK0VjjLul5JA3sFY8tEWv5CAH38IPOZ/QTqyfLD8iMcnA fm+UnaMNLOuWH9GpGW9yWiaF5OpFHoj1lVcyvXRQIymjM1/JPIS4FmHy4IGBueulxIjI /ry1S3JWLgmPLRs/7Gouqr1Ccioq/Dizwi97c4IG4JfpRuyVN9tMljxI9SEKIgVbDKqq 6KAtsTyT7SXMATLIijKJ49k0m0hAdBf09+ew+j5kLm24OX1XsW27MWyhvpLelxOmfovq bQeg== 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=s0Ak/xNC1dXDei9cjDRs41ZWc7vt5UFYJiQ0a6aU4Ys=; b=ftFSf5dogQp5skUKcD0pJi0f8iITqydqu60sp9xNMkRfz7zRjaQd1F1EC+XTL30JL+ 0Bo1Gbmznnnb6seABujNPwBQKBt8st272FLJzRFEyH7dviQK8uNNQgwqiZ0CX0ZOm+zT F8obIOPm87V7VxVKKMD0abXmIHWwtEeOPpRAA8fVEp7aPws/WFFUbPvwV0NayEsDnBlu w/fAAkQAm/acMSknAbLjS3HRZrBD73SDrIzyfVVTqCgXu4/LFV3d8gmEoJHFchG373Rh 1B3nhfAbdeeJgT8j6dhIQSDlIA65dIuTANwNBtX0hmHI9kzmxV0q32Lh4Bxtzbv2qs2w +02Q== X-Gm-Message-State: APt69E3r7Vi31dTyL8LFoc5t7np9BhSLUU0XaI5UGjGFsJr+MjNnR+ox VCmMBK4SiQQAzcyzoQCP+5KgUpexGpJX8k7vc+g= X-Google-Smtp-Source: ADUXVKJuvHiFOBidDOk001yjerFQKorU9Onro7yd6XEy0407Q2RmqR/0hh35nrckdI2J78oZdAqNfE5kYx6LCzfZUQQ= X-Received: by 2002:a0d:c105:: with SMTP id c5-v6mr1162421ywd.131.1528978368681; Thu, 14 Jun 2018 05:12:48 -0700 (PDT) MIME-Version: 1.0 References: <28C9E7B4-1D2F-4C65-A121-90E9AFB470AD@gmail.com> <7B87AAA7-E5C5-498E-A41E-8927BC554F29@consulintel.es> <966D347E-0A4F-4F51-90AB-03D178EF4CEB@consulintel.es> <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> In-Reply-To: From: Ca By Date: Thu, 14 Jun 2018 05:12:37 -0700 Message-ID: To: Lorenzo Colitti Cc: "Heatley, N, Nick, TQB R" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000088dd28056e990449" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 12:12:51 -0000 --00000000000088dd28056e990449 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti wrote: > On Thu, Jun 14, 2018 at 7:28 PM wrote: > >> If the requirement is do something better than NAT44 CGN then you can see >> why 464xlat has its place. >> >> MAP-T could in theory do this job. it seems more complex to deploy and >> the case to go from 464xlat to MAP-T seems weak, but if it really existed >> in mobile devices it may be something to consider. >> > > Oh, I definitely agree that 464xlat has it's place. I maintain a popular > implementation of it :-) > > I'm just saying it's not the best solution for a wireline network. > Perhaps. The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat. Afaik, there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share. _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000088dd28056e990449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org> wrote:
<= /div>
On= Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:

If the requirement is do something better than NAT44= CGN then you can see why 464xlat has its place.

MAP-T could in theory do this job. it seems mo= re complex to deploy and the case to go from 464xlat to MAP-T seems weak, b= ut if it really existed in mobile devices it may be something to consider.<= /span>


Oh, I definitely agree that 464xlat has it's pl= ace. I maintain a popular implementation of it :-)

I'm just saying it's not the best solution for a wireline network.= =C2=A0

Perhaps.=C2=A0

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.= =C2=A0

Afaik, there is n= ot a large production stateless MAP implementation, and this market is fair= ly mature. That said, at this point, the theoretical advantage of stateless= has failed to materialize in real world deployment ... while the stateful = solutions keep gaining share.=C2=A0


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000088dd28056e990449-- From nobody Thu Jun 14 06:16:09 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 A23FE130E1C for ; Thu, 14 Jun 2018 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl6bMdWcsylF for ; Thu, 14 Jun 2018 06:16:01 -0700 (PDT) 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 EC739130DEF for ; Thu, 14 Jun 2018 06:16:00 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5EDFwIn175014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 14 Jun 2018 09:15:58 -0400 Received: (qmail 24419 invoked by uid 0); 14 Jun 2018 13:15:58 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 14 Jun 2018 13:15:58 -0000 To: v6ops@ietf.org References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> From: Lee Howard Message-ID: <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> Date: Thu, 14 Jun 2018 09:15:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EB37A1DB299D054C70B144F3" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:16:08 -0000 This is a multi-part message in MIME format. --------------EB37A1DB299D054C70B144F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/14/2018 08:12 AM, Ca By wrote: > > > On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti > > wrote: > > On Thu, Jun 14, 2018 at 7:28 PM > wrote: > > > > Oh, I definitely agree that 464xlat has it's place. I maintain a > popular implementation of it :-) > > I'm just saying it's not the best solution for a wireline network. > > > Perhaps. > > The market for ipv6-only transition, afaik, is won by ds-lite and > 464xlat. > > Afaik, there is not a large production stateless MAP implementation, > and this market is fairly mature. That said, at this point, the > theoretical advantage of stateless has failed to materialize in real > world deployment ... while the stateful solutions keep gaining share. > Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 I see several that have deployed MAP. I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation. I think it's too soon to declare winners. Lee --------------EB37A1DB299D054C70B144F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 06/14/2018 08:12 AM, Ca By wrote:


On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:


Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-)

I'm just saying it's not the best solution for a wireline network. 

Perhaps. 

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat. 

Afaik, there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share. 



Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

I see several that have deployed MAP.

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation.

I think it's too soon to declare winners.

Lee



--------------EB37A1DB299D054C70B144F3-- From nobody Thu Jun 14 06:32:32 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 5181B131047 for ; Thu, 14 Jun 2018 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYrWlsbZxomY for ; Thu, 14 Jun 2018 06:32:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A67130E78 for ; Thu, 14 Jun 2018 06:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528983143; x=1529587943; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=1HvVj8JIZx1Qf3qWV4SToW0KZiPRilFRa7 5iyqsvAgU=; b=igscgcoOHMsztlOEsOABCQlPJNlfxk42Ot2tN1Mb1BKh66d6Lo 1pfHQA2DJrKQEf9hYI29ZeZJuVRP21hmeLVkS2NRp5imWV5P18IjTTd+HZP1E6Zy AigwnRVssjZ8qLiReslyxe6pb0OZcxzji7/IOXXeVCklT3J+KLbw3i8V8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 15:32:23 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 15:32:22 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789375.msg for ; Thu, 14 Jun 2018 15:32:21 +0200 X-MDRemoteIP: 2001:470:1f09:495:c8ce:b95f:ab49:fe5f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 15:32:21 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Thu, 14 Jun 2018 15:32:15 +0200 From: JORDI PALET MARTINEZ To: Lee Howard , Message-ID: Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> In-Reply-To: <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611835135_1433092209" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:32:30 -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_3611835135_1433092209 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I recall Windows Update 10 also has included CLAT support. I=E2=80=99m sure= this will happen more and more in different OSs, as it makes a lot of sens= e in networks that may already have NAT64. =20 I don=E2=80=99t think that will happen with MAP or DS-Lite (I mean having t= hose in the OSs). =20 If we are pushing for IPv6-only enterprise networks, the CLAT will be also = the way to ensure that old apps work, if the enterprise router don=E2=80=99= t have the CLAT already enabled. =20 Another important aspect, in my opinion, is that the implementation of CLAT= , even for a CPE, it is the much simpler one compared with any other one. Regarsd, Jordi =20 =20 =20 De: v6ops en nombre de Lee Howard Fecha: jueves, 14 de junio de 2018, 15:16 Para: Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas =20 =20 =20 On 06/14/2018 08:12 AM, Ca By wrote: =20 =20 On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti wrote: On Thu, Jun 14, 2018 at 7:28 PM wrote: =20 =20 Oh, I definitely agree that 464xlat has it's place. I maintain a popular im= plementation of it :-) =20 I'm just saying it's not the best solution for a wireline network.=20 =20 Perhaps.=20 =20 The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.= =20 =20 Afaik, there is not a large production stateless MAP implementation, and th= is market is fairly mature. That said, at this point, the theoretical advan= tage of stateless has failed to materialize in real world deployment ... wh= ile the stateful solutions keep gaining share.=20 =20 Crowd-sourced list of transition technologies various carriers have deploye= d: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO= _7NK9vcVApc/edit#gid=3D0 I see several that have deployed MAP.=20 I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early d= evelopment), and were the only game in town. 464xlat only has that advantag= e in mobile, since handsets are the only major CLAT implementation.=20 I think it's too soon to declare winners. Lee _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611835135_1433092209 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I recall Windows Update 10 also has included CLAT support. I= =E2=80=99m sure this will happen more and more in different OSs, as it make= s a lot of sense in networks that may already have NAT64.=

 

I don=E2=80=99t think that will happen = with MAP or DS-Lite (I mean having those in the OSs).

=

 

If we are pushing for IPv6-only enterprise = networks, the CLAT will be also the way to ensure that old apps work, if th= e enterprise router don=E2=80=99t have the CLAT already enabled.=

 

Another important aspect, in my = opinion, is that the implementation of CLAT, even for a CPE, it is the much= simpler one compared with any other one.

Regarsd,

Jordi

 

&= nbsp;

 

De: v6ops = <v6ops-bounces@ietf.org> en nombre de Lee Howard <lee@asgard.org&g= t;
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <= v6ops@ietf.org>
Asunto: Re: [v6ops] Disadvantages of MAP proto= cols -- Re: Is 464XLAT really inferior to all other IPv6 transition technol= ogies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-trans= ition-ipv4aas

 

 

 

On 06/14/2018 08:12 AM, Ca By wrote:

 

 

On Thu, Jun 14, 2018 at 3:31 AM Lorenz= o Colitti <lorenzo=3D40go= ogle.com@dmarc.ietf.org> wrote:

On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wro= te:

 

 

Oh, I definitely agree that 464xlat has it's place. I maintain a popular= implementation of it :-)

 

I'm just saying it's not the best solution= for a wireline network. 

 

Perhaps.&nbs= p;

 

The market for ipv6-only transition, afaik, is won by ds-lite and= 464xlat. 

 

Afaik, there is not a large production stateless MA= P implementation, and this market is fairly mature. That said, at this poin= t, the theoretical advantage of stateless has failed to materialize in real= world deployment ... while the stateful solutions keep gaining share. = ;

 



Crowd-sourced list of transition techn= ologies various carriers have deployed: h= ttps://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK= 9vcVApc/edit#gid=3D0

I see several that have deployed MAP.
<= br>I speculate that DS-Lite and NAT64 had early mover advantage (i.e., earl= y development), and were the only game in town. 464xlat only has that advan= tage in mobile, since handsets are the only major CLAT implementation.
=
I think it's too soon to declare winners.

Lee



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


**= ********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611835135_1433092209-- From nobody Thu Jun 14 06:43:44 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 34751130F1B for ; Thu, 14 Jun 2018 06:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAQkTv7Ip3Xu for ; Thu, 14 Jun 2018 06:43:41 -0700 (PDT) Received: from atl4mhob13.registeredsite.com (atl4mhob13.registeredsite.com [209.17.115.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F31130DEF for ; Thu, 14 Jun 2018 06:43:40 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob13.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5EDhbiP016991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 14 Jun 2018 09:43:38 -0400 Received: (qmail 7472 invoked by uid 0); 14 Jun 2018 13:43:37 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 14 Jun 2018 13:43:37 -0000 To: JORDI PALET MARTINEZ , v6ops@ietf.org References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> From: Lee Howard Message-ID: <405c3498-7159-6888-d756-f72346cb188d@asgard.org> Date: Thu, 14 Jun 2018 09:43:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3FEDDE671EA6BF07A921AB90" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:43:43 -0000 This is a multi-part message in MIME format. --------------3FEDDE671EA6BF07A921AB90 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 06/14/2018 09:32 AM, JORDI PALET MARTINEZ wrote: > > I recall Windows Update 10 also has included CLAT support. I’m sure > this will happen more and more in different OSs, as it makes a lot of > sense in networks that may already have NAT64. > You think? Like game console OSs and thermostat OSs and stereo OSs and TV OSs? > I don’t think that will happen with MAP or DS-Lite (I mean having > those in the OSs). > Ew, I hope not, that's the wrong place to implement those. I suppose I could imagine using a softwire as a VPN assuming IPv6--no, no I can't imagine it. > If we are pushing for IPv6-only enterprise networks, the CLAT will be > also the way to ensure that old apps work, if the enterprise router > don’t have the CLAT already enabled. > > Another important aspect, in my opinion, is that the implementation of > CLAT, even for a CPE, it is the much simpler one compared with any > other one. > That only matters if it actually gets implemented. "Easy" and "done" are different. You've said that home gateway vendors by and large have code for all of the mechanisms already written, so I'm not sure ease is essential. There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner. Lee > > Regarsd, > > Jordi > > *De: *v6ops en nombre de Lee Howard > > *Fecha: *jueves, 14 de junio de 2018, 15:16 > *Para: * > *Asunto: *Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT > really inferior to all other IPv6 transition technologies? -- Re: > updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas > > On 06/14/2018 08:12 AM, Ca By wrote: > > On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti > > wrote: > > On Thu, Jun 14, 2018 at 7:28 PM > wrote: > > Oh, I definitely agree that 464xlat has it's place. I maintain > a popular implementation of it :-) > > I'm just saying it's not the best solution for a wireline > network. > > Perhaps. > > The market for ipv6-only transition, afaik, is won by ds-lite and > 464xlat. > > Afaik, there is not a large production stateless MAP > implementation, and this market is fairly mature. That said, at > this point, the theoretical advantage of stateless has failed to > materialize in real world deployment ... while the stateful > solutions keep gaining share. > > > > Crowd-sourced list of transition technologies various carriers have > deployed: > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 > > I see several that have deployed MAP. > > I speculate that DS-Lite and NAT64 had early mover advantage (i.e., > early development), and were the only game in town. 464xlat only has > that advantage in mobile, since handsets are the only major CLAT > implementation. > > I think it's too soon to declare winners. > > Lee > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > --------------3FEDDE671EA6BF07A921AB90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 06/14/2018 09:32 AM, JORDI PALET MARTINEZ wrote:

I recall Windows Update 10 also has included CLAT support. I’m sure this will happen more and more in different OSs, as it makes a lot of sense in networks that may already have NAT64.


You think? Like game console OSs and thermostat OSs and stereo OSs and TV OSs?

 

I don’t think that will happen with MAP or DS-Lite (I mean having those in the OSs).


Ew, I hope not, that's the wrong place to implement those. I suppose I could imagine using a softwire as a VPN assuming IPv6--no, no I can't imagine it.

 

If we are pushing for IPv6-only enterprise networks, the CLAT will be also the way to ensure that old apps work, if the enterprise router don’t have the CLAT already enabled.

 

Another important aspect, in my opinion, is that the implementation of CLAT, even for a CPE, it is the much simpler one compared with any other one.


That only matters if it actually gets implemented. "Easy" and "done" are different.

You've said that home gateway vendors by and large have code for all of the mechanisms already written, so I'm not sure ease is essential.

There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner.

Lee
 


Regarsd,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee Howard <lee@asgard.org>
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

 

 

On 06/14/2018 08:12 AM, Ca By wrote:

 

 

On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:

On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:

 

 

Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-)

 

I'm just saying it's not the best solution for a wireline network. 

 

Perhaps. 

 

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat. 

 

Afaik, there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share. 

 



Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

I see several that have deployed MAP.

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation.

I think it's too soon to declare winners.

Lee



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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.


--------------3FEDDE671EA6BF07A921AB90-- From nobody Thu Jun 14 07:20: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 57C88130E13 for ; Thu, 14 Jun 2018 07:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZwv4xsBRLg1 for ; Thu, 14 Jun 2018 07:20:51 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901C612777C for ; Thu, 14 Jun 2018 07:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528986048; x=1529590848; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=8KxvhA6tvdZA1VLAgFcLIlyDNo/r7R8uhj cOW2XN4g0=; b=Pi2E/CiNTeTzpo8zTt0vYMlYwj/+8CFmRQTkEJ0+vc70qD848h fO7KDC2e2lUmur3oAHuDZNLgYuzF4fdPqjzo90GeJwVBVubjmEqRGVKCN3LilQDF NKeYzd2Pfwc7AAd6J15n0tN35ApSooDLRAi1C4/tVKPIue5p+TUnd9A5I= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 16:20:48 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 16:20:47 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789399.msg for ; Thu, 14 Jun 2018 16:20:46 +0200 X-MDRemoteIP: 2001:470:1f09:495:c8ce:b95f:ab49:fe5f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 16:20:46 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.0.180610 Date: Thu, 14 Jun 2018 16:20:42 +0200 From: JORDI PALET MARTINEZ To: Lee Howard , Message-ID: Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> In-Reply-To: <405c3498-7159-6888-d756-f72346cb188d@asgard.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611838042_2138395074" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 14:20: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_3611838042_2138395074 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 I recall Windows Update 10 also has included CLAT support. I=E2=80=99m sure= this will happen more and more in different OSs, as it makes a lot of sens= e in networks that may already have NAT64. You think? Like game console OSs and thermostat OSs and stereo OSs and TV O= Ss?=20 No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It= makes a lot of sense specially for devices that are =E2=80=9Cportable=E2= =80=9D and in fact that=E2=80=99s the idea behind Windows 10 Update. If you= can use that device in a cellular IPv6-only network, should be expected th= at in a WiFi or wired IPv6-only network is behaving the same way when no na= tive IPv4 is available. The other kind of OSs that you mention should eithe= r have already IPv6-only or rely in the CPE to provide IPv4 if they really = need that. =20 I don=E2=80=99t think that will happen with MAP or DS-Lite (I mean having t= hose in the OSs). Ew, I hope not, that's the wrong place to implement those. I suppose I coul= d imagine using a softwire as a VPN assuming IPv6--no, no I can't imagine i= t. Yes, as a VPN client, it may be, but hopefully not as something by default = in the OS. =20 If we are pushing for IPv6-only enterprise networks, the CLAT will be also = the way to ensure that old apps work, if the enterprise router don=E2=80=99= t have the CLAT already enabled. =20 Another important aspect, in my opinion, is that the implementation of CLAT= , even for a CPE, it is the much simpler one compared with any other one. That only matters if it actually gets implemented. "Easy" and "done" are di= fferent. You've said that home gateway vendors by and large have code for all of the= mechanisms already written, so I'm not sure ease is essential. Yeah, talked to many, they often provide whatever you need if the order is = big, our problem is still the retail market or orders to vendors that don= =E2=80=99t have sufficient amount to demand a specific firmware feature set= . =20 Code required for each transition in OpenWRT (it may be quite similar in ot= her implementations): =20 DS-Lite=C2=A0=C2=A0 15 Kbytes 464XLAT 17 Kbytes MAP-E =C2=A0=C2=A0=C2=A035 Kbytes LW4o6 =C2=A0=C2=A035 Kbytes MAP-T =C2=A0=C2=A048 Kbytes =20 If *all* them are implemented: 53 Kbytes (there are many =E2=80=9Cshared=E2= =80=9D modules among them, same data plane, etc.). There are other drivers here, and while I have no concerns about 464xlat, I= also am not ready to crown it the winner.=20 =20 I bet a dinner =E2=80=A6 Cellular is too powerful and they made the decisio= n long time ago. Lee =20 Regarsd, Jordi =20 =20 =20 De: v6ops en nombre de Lee Howard Fecha: jueves, 14 de junio de 2018, 15:16 Para: Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas =20 =20 =20 On 06/14/2018 08:12 AM, Ca By wrote: =20 =20 On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti wrote: On Thu, Jun 14, 2018 at 7:28 PM wrote: =20 =20 Oh, I definitely agree that 464xlat has it's place. I maintain a popular im= plementation of it :-) =20 I'm just saying it's not the best solution for a wireline network.=20 =20 Perhaps.=20 =20 The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.= =20 =20 Afaik, there is not a large production stateless MAP implementation, and th= is market is fairly mature. That said, at this point, the theoretical advan= tage of stateless has failed to materialize in real world deployment ... wh= ile the stateful solutions keep gaining share.=20 =20 Crowd-sourced list of transition technologies various carriers have deploye= d: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO= _7NK9vcVApc/edit#gid=3D0 I see several that have deployed MAP.=20 I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early d= evelopment), and were the only game in town. 464xlat only has that advantag= e in mobile, since handsets are the only major CLAT implementation.=20 I think it's too soon to declare winners. Lee _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611838042_2138395074 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

I reca= ll Windows Update 10 also has included CLAT support. I=E2=80=99m sure this = will happen more and more in different OSs, as it makes a lot of sense in n= etworks that may already have NAT64.


You th= ink? Like game console OSs and thermostat OSs and stereo OSs and TV OSs?

No,= I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It ma= kes a lot of sense specially for devices that are =E2=80=9Cportable=E2=80= =9D and in fact that=E2=80=99s the idea behind Windows 10 Update. If you ca= n use that device in a cellular IPv6-only network, should be expected that = in a WiFi or wired IPv6-only network is behaving the same way when no nativ= e IPv4 is available. The other kind of OSs that you mention should either h= ave already IPv6-only or rely in the CPE to provide IPv4 if they really nee= d that.

 

= I don=E2=80=99t thi= nk that will happen with MAP or DS-Lite (I mean having those in the OSs).


Ew, I hope not, that's the wrong place to implement those. I su= ppose I could imagine using a softwire as a VPN assuming IPv6--no, no I can= 't imagine it.


Yes, as a VPN client, it may be, but hopefully not as something by de= fault in the OS.

 

If we are pu= shing for IPv6-only enterprise networks, the CLAT will be also the way to e= nsure that old apps work, if the enterprise router don=E2=80=99t have the C= LAT already enabled.

&n= bsp;

Another important = aspect, in my opinion, is that the implementation of CLAT, even for a CPE, = it is the much simpler one compared with any other one.


That o= nly matters if it actually gets implemented. "Easy" and "don= e" are different.

You've said that home gateway vendors by and = large have code for all of the mechanisms already written, so I'm not sure = ease is essential.

Yeah, talked to many, they often provide whatever you need if the ord= er is big, our problem is still the retail market or orders to vendors that= don=E2=80=99t have sufficient amount to demand a specific firmware feature= set.

&nb= sp;

Code required f= or each transition in OpenWRT (it may be quite similar in other implementat= ions):

 

DS-Lite=C2=A0=C2=A0 15 Kbytes

464XLAT 17 Kbytes

MAP-E =C2=A0=C2=A0=C2=A035 Kbytes<= /o:p>

LW4o6 =C2=A0=C2=A035 Kbytes

MAP-T =C2=A0=C2=A048 Kbytes

 = ;

If *all* them are implem= ented: 53 Kbytes (there are many =E2=80=9Cshared=E2=80=9D modules among the= m, same data plane, etc.).


There are other drivers here= , and while I have no concerns about 464xlat, I also am not ready to crown = it the winner.

 

I bet= a dinner =E2=80=A6 Cellular is too powerful and they made the decision lon= g time ago.



Lee
 

<= /p>


Regarsd,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee How= ard <lee@asgard.org>
Fech= a: jueves, 14 de junio de 2018, 15:16
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] D= isadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all othe= r IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT = in draft-ietf-v6ops-transition-ipv4aas

 

 

 

On 06/14/2018 08:12 AM, Ca By wrote:<= /p>

 

=

 

On Thu, Jun 14= , 2018 at 3:31 AM Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org> wrote:

On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:=

 

 

Oh, I definitely agree that 464xlat has it's place. I mainta= in a popular implementation of it :-)

 

<= /div>

I'm just saying= it's not the best solution for a wireline network. 

 

Perhaps. 

 

The market for ipv6-only transition, a= faik, is won by ds-lite and 464xlat. 

 

=

Afaik, there is not a lar= ge production stateless MAP implementation, and this market is fairly matur= e. That said, at this point, the theoretical advantage of stateless has fai= led to materialize in real world deployment ... while the stateful solution= s keep gaining share. 

 



Crowd-source= d list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaR= dRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=3D0

I see several t= hat have deployed MAP.

I speculate that DS-Lite and NAT64 had early= mover advantage (i.e., early development), and were the only game in town.= 464xlat only has that advantage in mobile, since handsets are the only maj= or CLAT implementation.

I think it's too soon to declare winners.
Lee



_______________________________________________ v6= ops mailing list v6ops@ietf.org https://www.ietf.org/mai= lman/listinfo/v6ops

=
**********************************************
IPv4 is over
Are y= ou ready for the new Internet ?
ht= tp://www.consulintel.es
The IPv6 Company

This electronic mess= age contains information which may be privileged or confidential. The infor= mation is intended to be for the exclusive use of the individual(s) named a= bove and further non-explicilty authorized disclosure, copying, distributio= n or use of the contents of this information, even if partially, including = attached files, is strictly prohibited and will be considered a criminal of= fense. If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited, will be conside= red a criminal offense, so you must reply to the original sender to inform = about this communication and delete it.




= **********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611838042_2138395074-- From nobody Thu Jun 14 08:39:28 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 6BB7E130E45 for ; Thu, 14 Jun 2018 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 wnNL1gFbxim5 for ; Thu, 14 Jun 2018 08:39:25 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD6A130E34 for ; Thu, 14 Jun 2018 08:39:24 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id x4-v6so6922792wro.11 for ; Thu, 14 Jun 2018 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AhxcZK8hOG35DV2GWENkJ6Wgo0itpNCRIGHBwEUhhU8=; b=QZXTvNZhf65r7X+KbqP8XN/zT3dVKkQB24Jwd5pnseTlJuhTcNauwniZdMSkeVZIxc 68u99qAzmpzuzL+DJarGYvmRJWI0J94n8ZetcEUxmsP8kr2XX8005yFCOvTqJzVK4nA8 10WwrCgd18IKvyZ9I1J+uYlqoiWhWV/OxefPB6jG9tp0j/b9jFHMNzhWcy53XiBTUXV9 JD7pWgfgP0rIkw3kcJ64UUdYspYxxZa6pPJit8iCMwnIzNvPAUr86KF6U67iABOcN/BJ XaycZ6kX36PeTIEdxv4+uSt30QNQNgWi1d6cZyKmdHvZ5Hf6wd1VcLOK5BRa8NqD0TMh gXHw== 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=AhxcZK8hOG35DV2GWENkJ6Wgo0itpNCRIGHBwEUhhU8=; b=k0KYrMvue0pclMEHwtBXHGvCAt2Qe8Laxcy0JM1QmbP6ZxWWDOeEzcBUpxojsnvzQe 7e3VF2KHMoY8nNX4IMPIPO+MX7ca6WMVK0jiZNv21BcdxL1KAlNwgeye4bFE1fD0JJbf sW4mnXcgqJ3yvgL5DNcCTZgZd8NiOCxXFScSIkb7q0KjijeqvuqWLmRT/y+L6ghOswxt mzJVykOudS92DPpbRECVIk4Cx1q1q7b0AWuaJMHU7jak32v33/I9OhV7u12R6ELkAX9j iIErrf50AP/VYMiMztnwfxY4+1Vg3zLv24TbKQVf6VUJYY8steZvxFpGP+o+bQ9CpcMm /bcw== X-Gm-Message-State: APt69E1ys4agy+7FYzY6nGZHJABGwH1wEK5HB0MHUSzbTHumtwWGRFat PVU8cAg4xt4nELMjqwjVpfiahuuacc+kIK9TCGC7wQ== X-Google-Smtp-Source: ADUXVKLSRx7zjoiBWxh9uG+JPj+RGCs/LQ8xzf/Vr8EF/pfZZ2qzgpl+u/6MFzSNA3on7fgC7Hjk6aBHOvvsndQ/f58= X-Received: by 2002:a5d:49d1:: with SMTP id t17-v6mr2599739wrs.242.1528990762882; Thu, 14 Jun 2018 08:39:22 -0700 (PDT) MIME-Version: 1.0 References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> In-Reply-To: From: Lorenzo Colitti Date: Fri, 15 Jun 2018 00:39:09 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: Lee Howard , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000049c912056e9be7a6" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:39:27 -0000 --00000000000049c912056e9be7a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET MARTINEZ wrote: > There are other drivers here, and while I have no concerns about 464xlat, > I also am not ready to crown it the winner. > > > > I bet a dinner =E2=80=A6 Cellular is too powerful and they made the decis= ion long > time ago. > Actually, the real solution for mobile is true IPv6-only with NAT64. Mobile is going to get there much faster than wireline, There's not that far much left to do (Apple has already done it), and handsets are much more under the control of carriers and churn so much more quickly. --00000000000049c912056e9be7a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 14= , 2018 at 11:21 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> w= rote:

There are = other drivers here, and while I have no concerns about 464xlat, I also am n= ot ready to crown it the winner.

=C2=A0

I bet a dinner =E2=80=A6 Cellular is too powerfu= l and they made the decision long time ago.


Actually, the real solution for mobile is true IPv6= -only with NAT64. Mobile is going to get there much faster than wireline, T= here's not that far much left to do (Apple has already done it), and=C2=A0hand= sets are much more under the control of carriers and churn so much more qui= ckly.
--00000000000049c912056e9be7a6-- From nobody Thu Jun 14 08:43: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 85DDF130E22 for ; Thu, 14 Jun 2018 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9iMNZvIMoMZ for ; Thu, 14 Jun 2018 08:43:46 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7003130DFB for ; Thu, 14 Jun 2018 08:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528991023; x=1529595823; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=tpGyQoOR9WezX22s6EP5vH NzwaNJ7xrga+39DtUvAyA=; b=bnOcC9yjxsXnEfS1vZvwrUbjQxQuFXEym5fuzo arN1R0mxPv6c3PXLOhulIpncAQG31GE0boNZzQ94hB2uiK8G3AgoDIptBXGZVb04 SwcH3n7x+bA5HU/bbfu/FRComMHHQPyiqNfaN0V7t00Fd5RVIwa0UrczHrK6S2mN GkjFk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 17:43:43 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 17:43:43 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789456.msg for ; Thu, 14 Jun 2018 17:43:42 +0200 X-MDRemoteIP: 2001:470:1f09:495:c8ce:b95f:ab49:fe5f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 17:43:42 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 14 Jun 2018 17:43:40 +0200 From: JORDI PALET MARTINEZ To: Lorenzo Colitti CC: Lee Howard , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611843020_1577032223" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:43:49 -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_3611843020_1577032223 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable But, and is a big but, for tethering the CLAT is needed, otherwise the oper= ator need to provide also an IPv4v6 PDP context just for the tethering. =20 This is the actual complain from many operators with iOS, which is sorted o= ut in Android and Windows with the CLAT. =20 At least while some devices are IPv4-only and people need to use them with = tethering. Regards, Jordi =20 =20 =20 De: Lorenzo Colitti Fecha: jueves, 14 de junio de 2018, 17:39 Para: CC: Lee Howard , "v6ops@ietf.org WG" Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas =20 On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET MARTINEZ wrote: There are other drivers here, and while I have no concerns about 464xlat, I= also am not ready to crown it the winner.=20 =20 I bet a dinner =E2=80=A6 Cellular is too powerful and they made the decisio= n long time ago. =20 Actually, the real solution for mobile is true IPv6-only with NAT64. Mobile= is going to get there much faster than wireline, There's not that far much= left to do (Apple has already done it), and handsets are much more under t= he control of carriers and churn so much more quickly. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611843020_1577032223 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

But, and is a big but, for tethering the CLAT is needed, othe= rwise the operator need to provide also an IPv4v6 PDP context just for the = tethering.

 

This is the= actual complain from many operators with iOS, which is sorted out in Andro= id and Windows with the CLAT.

 

At least while some devices are IPv4-only and people need to use th= em with tethering.


Regards,

=

Jordi<= /o:p>

 

 

=  

De: = Lorenzo Colitti <lorenzo=3D= 40google.com@dmarc.ietf.org>
Fecha: jueves, 14 de junio de 201= 8, 17:39
Para: <jordi.palet@consulintel.es>
CC: L= ee Howard <lee@asgard.org>, "v6ops@ietf.org WG" <v6ops@i= etf.org>
Asunto: Re: [v6ops] Disadvantages of MAP protocols --= Re: Is 464XLAT really inferior to all other IPv6 transition technologies? = -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-i= pv4aas

 

On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET= MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

There are other drivers here, and while I have = no concerns about 464xlat, I also am not ready to crown it the winner.

 

I bet a dinner= =E2=80=A6 Cellular is too powerful and they made the decision long time ag= o.

 

Actually, the real solution for mobile = is true IPv6-only with NAT64. Mobile is going to get there much faster than= wireline, There's not that far much left to do (Apple has already done it), and handsets are much more u= nder the control of carriers and churn so much more quickly.

=

**********************************************<= br> IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611843020_1577032223-- From nobody Thu Jun 14 08:47: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 E62BE130E54 for ; Thu, 14 Jun 2018 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hB9oL458OLSP for ; Thu, 14 Jun 2018 08:47:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F8E130DFB for ; Thu, 14 Jun 2018 08:47:29 -0700 (PDT) Received: from tpw09926dag14g.domain1.systemhost.net (10.9.212.30) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 16:47:57 +0100 Received: from tpw09926dag14h.domain1.systemhost.net (10.9.212.38) by tpw09926dag14g.domain1.systemhost.net (10.9.212.30) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 14 Jun 2018 16:47:26 +0100 Received: from RDW083A008ED64.bt.com (10.187.98.13) by tpw09926dag14h.domain1.systemhost.net (10.9.212.38) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Thu, 14 Jun 2018 16:47:26 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (23.103.134.143) by smtpe1.intersmtp.com (62.239.224.237) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 16:47:21 +0100 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:X-MS-Exchange-SenderADCheck; bh=WV1g4xl//JdqB3jFCxlZs/AVSYjnl+5IKDY38AVaWYM=; b=pM2rAxsFCgZI/mnTqtKEnAX13DN+Rit2zUV1H9WcWHBtHoR09bY16PEV4xaaovkiOIM21KG9jqZxErCDbm7yunNrNiT0LMrDVEu6TSOeZM+P2wagj47R5EVBNfqqElpOfPrfc3SBG2mITUZv0fsVstpFtNY64yR3NS9UfCYtpFM= Received: from LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM (10.167.24.141) by LO1P123MB1155.GBRP123.PROD.OUTLOOK.COM (10.167.27.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Thu, 14 Jun 2018 15:47:19 +0000 Received: from LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM ([fe80::447b:b457:ce32:4a88]) by LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM ([fe80::447b:b457:ce32:4a88%7]) with mapi id 15.20.0863.016; Thu, 14 Jun 2018 15:47:19 +0000 From: To: , CC: Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUA8LDRjDhXVibNU6g9q4o+7Bxy6RfgS2AgAAMzwCAABx1gIAAEbEAgAAEj4CAAAMtgIAAClwAgAAV7ICAAAIigA== Date: Thu, 14 Jun 2018 15:47:19 +0000 Message-ID: References: <018DD24B-DD2F-4B31-A939-328173891F3E@consulintel.es> <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> 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; LO1P123MB1155; 7:7iIHKOaHS0OOaQFv6juKxgFnjC/3PAEGimuPOqD2tF7bEa0sKCUw5kb0WgxCPzcUecmXUk7KwGaF/wpfWpYE42TM1tjC33GAB9T+kbPybfmMymsIU8U900gRMm4Z0FwVlpbAIq58UBsQwnSBtZSHAEgrDQMOtD+CVln5vO7IGB6gBhja2bWZ/IHC1rKnpkPq6z7tnQFGAzoXQom2c7ZTyjcPVP1QHjbVtweOt/ahGgaxFRbdM/vF3qtpXi9bJUmg x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cd7187ca-81b7-420c-a3da-08d5d20e1ccb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:LO1P123MB1155; x-ms-traffictypediagnostic: LO1P123MB1155: x-antispam-2: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:LO1P123MB1155; BCL:0; PCL:0; RULEID:; SRVR:LO1P123MB1155; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39380400002)(39860400002)(346002)(189003)(199004)(3660700001)(53936002)(14454004)(229853002)(186003)(33656002)(26005)(6436002)(106356001)(105586002)(11346002)(446003)(55016002)(5250100002)(2900100001)(6506007)(76176011)(102836004)(53546011)(54896002)(9686003)(3280700002)(6306002)(97736004)(236005)(7696005)(110136005)(25786009)(68736007)(5660300001)(4326008)(2906002)(7736002)(3846002)(81166006)(790700001)(476003)(6246003)(8936002)(478600001)(6116002)(8676002)(81156014)(74316002)(486006)(99286004)(66066001)(86362001)(93886005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB1155; H:LO1P123MB0098.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UOVrcykAXM6DaBWB7nylmabGE4MCGeJoen69z0xz1AoA5Z7PbG8pmFUyRwnYefvck4USzONIE+3JSfaoRvdaZO8EXKlvXn2EH+s5OhX8xSNUKM0GvFFOtIcItxPlztWxHF0W/9hIK52Rlz1BGFhKgy74gDPwD9TEUrmW2optd/7CN1Hh207znnptBcJrYWoe spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB0098B5E3B8C3C7014BFA3B79EA7D0LO1P123MB0098GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cd7187ca-81b7-420c-a3da-08d5d20e1ccb X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 15:47:19.6145 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB1155 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:47:35 -0000 --_000_LO1P123MB0098B5E3B8C3C7014BFA3B79EA7D0LO1P123MB0098GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZS4NClRoZSBnYXA6IHRldGhlcmluZyBhbiB1bmtub3duIGRldmljZSAoaS5lLiBP UyBtYXkgZGVwZW5kIG9uIHY0KSB0byBhIElQdjYtb25seSBjZWxsdWxhciBkZXZpY2UuDQo0NjR4 bGF0IG5haWxzIHRoYXQgdXNlIGNhc2Ugb24gYSBzaW5nbGUgQVBOLg0KDQpGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0 dGkNClNlbnQ6IDE0IEp1bmUgMjAxOCAxNjozOQ0KVG86IGpvcmRpLnBhbGV0PTQwY29uc3VsaW50 ZWwuZXNAZG1hcmMuaWV0Zi5vcmcNCkNjOiB2Nm9wc0BpZXRmLm9yZyBXRyA8djZvcHNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBEaXNhZHZhbnRhZ2VzIG9mIE1BUCBwcm90b2NvbHMg LS0gUmU6IElzIDQ2NFhMQVQgcmVhbGx5IGluZmVyaW9yIHRvIGFsbCBvdGhlciBJUHY2IHRyYW5z aXRpb24gdGVjaG5vbG9naWVzPyAtLSBSZTogdXBkYXRpbmcgUkZDODAyNiB0byBzdXBwb3J0IDQ2 NFhMQVQgaW4gZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMNCg0KT24gVGh1LCBK dW4gMTQsIDIwMTggYXQgMTE6MjEgUE0gSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0 PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY29uc3VsaW50ZWwuZXNA ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNClRoZXJlIGFyZSBvdGhlciBkcml2ZXJzIGhlcmUsIGFu ZCB3aGlsZSBJIGhhdmUgbm8gY29uY2VybnMgYWJvdXQgNDY0eGxhdCwgSSBhbHNvIGFtIG5vdCBy ZWFkeSB0byBjcm93biBpdCB0aGUgd2lubmVyLg0KDQpJIGJldCBhIGRpbm5lciDigKYgQ2VsbHVs YXIgaXMgdG9vIHBvd2VyZnVsIGFuZCB0aGV5IG1hZGUgdGhlIGRlY2lzaW9uIGxvbmcgdGltZSBh Z28uDQoNCkFjdHVhbGx5LCB0aGUgcmVhbCBzb2x1dGlvbiBmb3IgbW9iaWxlIGlzIHRydWUgSVB2 Ni1vbmx5IHdpdGggTkFUNjQuIE1vYmlsZSBpcyBnb2luZyB0byBnZXQgdGhlcmUgbXVjaCBmYXN0 ZXIgdGhhbiB3aXJlbGluZSwgVGhlcmUncyBub3QgdGhhdCBmYXIgbXVjaCBsZWZ0IHRvIGRvIChB cHBsZSBoYXMgYWxyZWFkeSBkb25lIGl0KSwgYW5kIGhhbmRzZXRzIGFyZSBtdWNoIG1vcmUgdW5k ZXIgdGhlIGNvbnRyb2wgb2YgY2FycmllcnMgYW5kIGNodXJuIHNvIG11Y2ggbW9yZSBxdWlja2x5 Lg0K --_000_LO1P123MB0098B5E3B8C3C7014BFA3B79EA7D0LO1P123MB0098GBRP_ 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 b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRpc2FncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+VGhlIGdhcDogdGV0aGVyaW5nIGFuIHVua25vd24gZGV2aWNlIChpLmUuIE9TIG1heSBkZXBl bmQgb24gdjQpIHRvIGEgSVB2Ni1vbmx5IGNlbGx1bGFyIGRldmljZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjQ2NHhsYXQgbmFpbHMgdGhhdCB1c2UgY2FzZSBvbiBhIHNpbmdsZSBBUE4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50Ojwv Yj4gMTQgSnVuZSAyMDE4IDE2OjM5PGJyPg0KPGI+VG86PC9iPiBqb3JkaS5wYWxldD00MGNvbnN1 bGludGVsLmVzQGRtYXJjLmlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZyBX RyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNd IERpc2FkdmFudGFnZXMgb2YgTUFQIHByb3RvY29scyAtLSBSZTogSXMgNDY0WExBVCByZWFsbHkg aW5mZXJpb3IgdG8gYWxsIG90aGVyIElQdjYgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXM/IC0tIFJl OiB1cGRhdGluZyBSRkM4MDI2IHRvIHN1cHBvcnQgNDY0WExBVCBpbiBkcmFmdC1pZXRmLXY2b3Bz LXRyYW5zaXRpb24taXB2NGFhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMTQsIDIwMTggYXQgMTE6MjEgUE0gSk9SREkgUEFM RVQgTUFSVElORVogJmx0O2pvcmRpLnBhbGV0PTxhIGhyZWY9Im1haWx0bzo0MGNvbnN1bGludGVs LmVzQGRtYXJjLmlldGYub3JnIj40MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPlRoZXJlIGFyZSBvdGhlciBkcml2ZXJzIGhlcmUsIGFuZCB3aGlsZSBJIGhhdmUg bm8gY29uY2VybnMgYWJvdXQgNDY0eGxhdCwgSSBhbHNvIGFtIG5vdCByZWFkeSB0byBjcm93biBp dCB0aGUgd2lubmVyLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYmV0IGEgZGlubmVyIOKApiBDZWxsdWxhciBp cyB0b28gcG93ZXJmdWwgYW5kIHRoZXkgbWFkZSB0aGUgZGVjaXNpb24gbG9uZyB0aW1lIGFnby48 L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY3R1YWxs eSwgdGhlIHJlYWwgc29sdXRpb24gZm9yIG1vYmlsZSBpcyB0cnVlIElQdjYtb25seSB3aXRoIE5B VDY0LiBNb2JpbGUgaXMgZ29pbmcgdG8gZ2V0IHRoZXJlIG11Y2ggZmFzdGVyIHRoYW4gd2lyZWxp bmUsIFRoZXJlJ3Mgbm90IHRoYXQgZmFyIG11Y2ggbGVmdCB0byBkbyAoPHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPkFwcGxlIGhhcyBhbHJlYWR5IGRvbmUgaXQpLCBhbmQmbmJzcDs8L3Nw YW4+aGFuZHNldHMNCiBhcmUgbXVjaCBtb3JlIHVuZGVyIHRoZSBjb250cm9sIG9mIGNhcnJpZXJz IGFuZCBjaHVybiBzbyBtdWNoIG1vcmUgcXVpY2tseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_LO1P123MB0098B5E3B8C3C7014BFA3B79EA7D0LO1P123MB0098GBRP_-- From nobody Thu Jun 14 09:22: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 77685130E7E; Thu, 14 Jun 2018 09:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhE5Od49gpBu; Thu, 14 Jun 2018 09:21:51 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AD1130E26; Thu, 14 Jun 2018 09:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528993308; x=1529598108; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=95qjzdjqD4+1A9YOreKW7 ceQ67EuDW63AIgxajOS+Zc=; b=rY+2JYn7G8lsUVLexEbRbXFgQWiSXLlG/3OU4 FjYb984Yhf+htkSLkNn+ZhjYwZ2wP6jd8JhfVC8d/X0IZZSJXBZWQXY1NSEXXdeJ vWIfVqCdt7pTF4hebccMfPf6g0R5Hm4BCHQ2I41Wd7qmhYXx4tNZR84Fuef7N3xD 90e81M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 18:21:48 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 18:21:48 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789483.msg; Thu, 14 Jun 2018 18:21:47 +0200 X-MDRemoteIP: 2001:470:1f09:495:c8ce:b95f:ab49:fe5f X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 18:21:47 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 14 Jun 2018 18:21:43 +0200 From: JORDI PALET MARTINEZ To: , , Message-ID: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> Thread-Topic: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 16:21:53 -0000 Hi all, After a long chat with the authors of RFC8026, we have found an alternative solution which avoids updating RFC8026 and also avoids requiring a new option code for 464XLAT, as there is already one that we can use, which is related to NAT64, so still can use RFC8026 for our original intend of prioritizing and managing the available mechanism from the operator network. Consequently, we are working in a new version of draft-ietf-v6ops-transition-ipv4aas, which will be posted ASAP in v6ops. Anyway, we had lot of fun in v6ops because this, and I think every comment has been very useful! Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Thu Jun 14 09:54: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 E7037130DD5 for ; Thu, 14 Jun 2018 09:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KtH7ySzJCQg for ; Thu, 14 Jun 2018 09:54:51 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CED01294D0 for ; Thu, 14 Jun 2018 09:54:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w5EGsoYq039838; Thu, 14 Jun 2018 09:54:50 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w5EGsgNa039780 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 14 Jun 2018 09:54:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 14 Jun 2018 09:54:41 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Thu, 14 Jun 2018 09:54:41 -0700 From: "Templin (US), Fred L" To: Fred Baker CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] IETF 102 Agenda Thread-Index: AQHT/40dm7H3mQ/Oa0qSxuSjbjYCZaRbSonAgACUvQCABB8gwA== Date: Thu, 14 Jun 2018 16:54:41 +0000 Message-ID: <814050fd14f44a5a86d6869a8f34fd3e@XCH15-06-08.nw.nos.boeing.com> References: <74F1C837-D187-48EF-9804-E7DCDD7DF14D@gmail.com> <3c985cdd540948f29d92ee30f497988b@XCH15-06-08.nw.nos.boeing.com> <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> In-Reply-To: <503C593F-882B-4DB0-B204-CFE5EDA7FA13@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IETF 102 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 16:54:54 -0000 Hi Fred, I went carefully over all of the comments received since IETF101 and have s= ubmitted a -21 revision that I think should satisfy the comments raised (see below). H= ere is the changelog: --- Changes from -20to -21: o Re-worked classic routing model section o Included multi-addressing case where addresses may be assigned to applications o Removed strong/weak end system discussions --- I also changed the title to "Multi-Addressing Considerations for IPv6 Prefi= x Delegation" because the focus is really on multi-addressing considerations in the prese= nce of prefix delegation and not as much on prefix delegation "models". Please consider this version for presentation at IETF102. Thanks - Fred fred.l.templin@boeing.com ---- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multi-Addressing Considerations for IPv6 Prefix D= elegation Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-21.txt Pages : 14 Date : 2018-06-14 Abstract: IPv6 prefixes are typically delegated to requesting routers which assign them to their downstream-attached links and networks. The requesting node can provision the prefix according to whether it acts as a router on behalf of any downstream networks and/or as a host on behalf of its local applications. In the latter case, the requesting node can use portions of the delegated prefix for its own multi- addressing purposes. This document therefore considers prefix delegation consideations for both the classic routing and various multi-addressing use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-21 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-21 > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Monday, June 11, 2018 11:47 AM > To: Templin (US), Fred L > Cc: v6ops@ietf.org list > Subject: Re: [v6ops] IETF 102 Agenda >=20 > On Jun 11, 2018, at 9:59 AM, Templin (US), Fred L wrote: > > Hi Fred, > > > > 'draft-templin-v6ops-pdhost' has been updated, and received list traffi= c both > > before and after the update was posted. Please add to the agenda. > > > > Thanks - Fred >=20 > Hi. I'm looking at the discussion post-IETF-101, and looking for someone = saying "I support this draft. I think it describes something I > want to deploy in my network." This is an operational working group; I'm = looking especially for comments from network operators. > This is a discussion you and I have had a number of times. What the chair= s want to give agenda time to is drafts that the working group > participants find useful and interesting. We gauge that from list discuss= ion. So it's not "number of comments, when comments are > specifically solicited, exceed zero", but "someone said it was useful and= interesting in their deployment". >=20 > Since IETF 101, we have had two threads on the subject of pdhost. I initi= ated "let's discuss this" in late April: > https://www.ietf.org/mail-archive/web/v6ops/current/msg29222.html. >=20 > In that thread, we had comments from > - Dusan Medric, who wondered whether there was a discussion of allocati= ng a prefix (such as a /64) to a host, > - Joe Touch, Mark Smith, and Ole Troan regarding the distinction a "wea= k" and a "strong" host and between a "platform", a "router", > a "host", and a "node", and > - Alexandre Petrescu, on the utility in his IOT MIPv6 network. >=20 > I initiated another after your update on 29 May (https://www.ietf.org/mai= l-archive/web/v6ops/current/msg29275.html). In that, you > and Alexandre Petrescu discussed the utility of this in his IOT environme= nt, in which he wanted to use RFC 3633 to delegate a prefix to > an IOT router for use in an enclave in his network. You and he disagreed = on what was to be done with the delegated prefix. >=20 > I'm still looking for a comment from a working group participant saying s= /he finds draft-templin-v6ops-pdhost, in its 21st revision, > "useful and interesting". What I see is 14 emails since IETF 101, many of= which you responded to, from people who fundamentally > disagreed with you on one point or another. >=20 > General comment to those on the CC line: if this draft describes somethin= g useful to you in your network, your comment can > dramatically change the conversation between Fred and myself. From nobody Thu Jun 14 10:34: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 88216130E44 for ; Thu, 14 Jun 2018 10:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYc3eK546_96 for ; Thu, 14 Jun 2018 10:33:59 -0700 (PDT) Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4826F12785F for ; Thu, 14 Jun 2018 10:33:59 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5EHXu87180552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 14 Jun 2018 13:33:56 -0400 Received: (qmail 18678 invoked by uid 0); 14 Jun 2018 17:33:56 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 14 Jun 2018 17:33:55 -0000 To: JORDI PALET MARTINEZ , v6ops@ietf.org References: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> From: Lee Howard Message-ID: <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> Date: Thu, 14 Jun 2018 13:33:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------99AE347E9279FF927AAF7D99" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 17:34:03 -0000 This is a multi-part message in MIME format. --------------99AE347E9279FF927AAF7D99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 06/14/2018 10:20 AM, JORDI PALET MARTINEZ wrote: > > I recall Windows Update 10 also has included CLAT support. I’m > sure this will happen more and more in different OSs, as it makes > a lot of sense in networks that may already have NAT64. > > > You think? Like game console OSs and thermostat OSs and stereo OSs and > TV OSs? > > > No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, > Android). It makes a lot of sense specially for devices that are > “portable” and in fact that’s the idea behind Windows 10 Update. If > you can use that device in a cellular IPv6-only network, should be > expected that in a WiFi or wired IPv6-only network is behaving the > same way when no native IPv4 is available. The other kind of OSs that > you mention should either have already IPv6-only or rely in the CPE to > provide IPv4 if they really need that. > "Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so they need whatever the home gateway provides. No transition mechanisms are widespread in retail gateways; DS-Lite more than others. So we're waiting to see what goes into retail gateways. Meanwhile, manufacturers are asking ISP customers what they want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP. BUT it would be cool if game consoles did deploy CLAT, and provide a translation layer for games that only know IPv4. I don't know the architecture well enough to know whether that would work, Also, tethering behind an IPv6-only phone is still no problem if you have Windows 10 and a NAT64 server, apparently: just fire up the CLAT. > > That only matters if it actually gets implemented. "Easy" and "done" > are different. > > You've said that home gateway vendors by and large have code for all > of the mechanisms already written, so I'm not sure ease is essential. > > Yeah, talked to many, they often provide whatever you need if the > order is big, our problem is still the retail market or orders to > vendors that don’t have sufficient amount to demand a specific > firmware feature set. > > Code required for each transition in OpenWRT (it may be quite similar > in other implementations): > > DS-Lite   15 Kbytes > > 464XLAT 17 Kbytes > > MAP-E    35 Kbytes > > LW4o6   35 Kbytes > > MAP-T   48 Kbytes > > If *all* them are implemented: 53 Kbytes (there are many “shared” > modules among them, same data plane, etc.). > > > There are other drivers here, and while I have no concerns about > 464xlat, I also am not ready to crown it the winner. > > I bet a dinner … Cellular is too powerful and they made the decision > long time ago. > What's the decision criterion? :) Mobile is huge, but has little influence on wireline. And most of them (globally) are still on dual stack. Lee > > > > Lee > > > > Regarsd, > > Jordi > > *De: *v6ops > en nombre de Lee Howard > > *Fecha: *jueves, 14 de junio de 2018, 15:16 > *Para: * > *Asunto: *Re: [v6ops] Disadvantages of MAP protocols -- Re: Is > 464XLAT really inferior to all other IPv6 transition technologies? > -- Re: updating RFC8026 to support 464XLAT in > draft-ietf-v6ops-transition-ipv4aas > > On 06/14/2018 08:12 AM, Ca By wrote: > > On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti > > wrote: > > On Thu, Jun 14, 2018 at 7:28 PM > wrote: > > Oh, I definitely agree that 464xlat has it's place. I > maintain a popular implementation of it :-) > > I'm just saying it's not the best solution for a wireline > network. > > Perhaps. > > The market for ipv6-only transition, afaik, is won by ds-lite > and 464xlat. > > Afaik, there is not a large production stateless MAP > implementation, and this market is fairly mature. That said, > at this point, the theoretical advantage of stateless has > failed to materialize in real world deployment ... while the > stateful solutions keep gaining share. > > > > Crowd-sourced list of transition technologies various carriers > have deployed: > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 > > I see several that have deployed MAP. > > I speculate that DS-Lite and NAT64 had early mover advantage > (i.e., early development), and were the only game in town. 464xlat > only has that advantage in mobile, since handsets are the only > major CLAT implementation. > > I think it's too soon to declare winners. > > Lee > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the exclusive use of the individual(s) named above and further > non-explicilty authorized disclosure, copying, distribution or use > of the contents of this information, even if partially, including > attached files, is strictly prohibited and will be considered a > criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, > is strictly prohibited, will be considered a criminal offense, so > you must reply to the original sender to inform about this > communication and delete it. > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > --------------99AE347E9279FF927AAF7D99 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 06/14/2018 10:20 AM, JORDI PALET MARTINEZ wrote:

 

I recall Windows Update 10 also has included CLAT support. I’m sure this will happen more and more in different OSs, as it makes a lot of sense in networks that may already have NAT64.


You think? Like game console OSs and thermostat OSs and stereo OSs and TV OSs?


No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It makes a lot of sense specially for devices that are “portable” and in fact that’s the idea behind Windows 10 Update. If you can use that device in a cellular IPv6-only network, should be expected that in a WiFi or wired IPv6-only network is behaving the same way when no native IPv4 is available. The other kind of OSs that you mention should either have already IPv6-only or rely in the CPE to provide IPv4 if they really need that.


"Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so they need whatever the home gateway provides. No transition mechanisms are widespread in retail gateways; DS-Lite more than others. So we're waiting to see what goes into retail gateways.
Meanwhile, manufacturers are asking ISP customers what they want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.

BUT it would be cool if game consoles did deploy CLAT, and provide a translation layer for games that only know IPv4. I don't know the architecture well enough to know whether that would work,

Also, tethering behind an IPv6-only phone is still no problem if you have Windows 10 and a NAT64 server, apparently: just fire up the CLAT.


That only matters if it actually gets implemented. "Easy" and "done" are different.

You've said that home gateway vendors by and large have code for all of the mechanisms already written, so I'm not sure ease is essential.

Yeah, talked to many, they often provide whatever you need if the order is big, our problem is still the retail market or orders to vendors that don’t have sufficient amount to demand a specific firmware feature set.

 

Code required for each transition in OpenWRT (it may be quite similar in other implementations):

 

DS-Lite   15 Kbytes

464XLAT 17 Kbytes

MAP-E    35 Kbytes

LW4o6   35 Kbytes

MAP-T   48 Kbytes

 

If *all* them are implemented: 53 Kbytes (there are many “shared” modules among them, same data plane, etc.).


There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner.

 

I bet a dinner … Cellular is too powerful and they made the decision long time ago.


What's the decision criterion? :)
Mobile is huge, but has little influence on wireline. And most of them (globally) are still on dual stack.

Lee



Lee
 


Regarsd,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee Howard <lee@asgard.org>
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

 

 

On 06/14/2018 08:12 AM, Ca By wrote:

 

 

On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:

On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:

 

 

Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-)

 

I'm just saying it's not the best solution for a wireline network. 

 

Perhaps. 

 

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat. 

 

Afaik, there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share. 

 



Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

I see several that have deployed MAP.

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation.

I think it's too soon to declare winners.

Lee



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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.


--------------99AE347E9279FF927AAF7D99-- From nobody Thu Jun 14 10:53: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 F0B81130E44 for ; Thu, 14 Jun 2018 10:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FqxXoCT0BQww for ; Thu, 14 Jun 2018 10:52:44 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E56412785F for ; Thu, 14 Jun 2018 10:52:44 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id v131-v6so13579415wma.1 for ; Thu, 14 Jun 2018 10:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DhlZgVoFBd7KlsslHrW7X7SL6+wQCk5RWEhHjMang/s=; b=fB2ju7VkP7NhxMSA7MBQxg/J1ikswYL/Kvvs+6tYUz8UDuwKpPa+lKUkdpvUwp2f6m Z7XGdSUp3ZD7oZ01q+FupNR0X69wXgfOYMyo/kmwgr/VMefcw7OT6StFZ8P3rfd2nujj SL8VOoRNB6w2E10qAcfRuk7F9V9II/lr3jrZ9/dC6hvQLQZ7Mpifv+Ox1UGPAAa3zQLO LxaZPdSAd/aV6GWd7uTtlHygcVMuyuFUiue2mhc1jRvdnxqr7FhP2PtSpb1cF3xS/Iaa sZWefLQIgM19Bbqi8dV/7G8AwQpj4E5TF3FXifI388oDD19PeGSlnaH7IHJD2ZJbsA03 uirw== 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=DhlZgVoFBd7KlsslHrW7X7SL6+wQCk5RWEhHjMang/s=; b=QVhxwsCXDSo9+E59queYE8RFFvuYWHfjiqoabopJTPibQ21vmU5924dwYa6vOI/NmK zqwCPBZai/YMO3w7oEaLjO1hgLpSphEHjx+vmR6Zh/VEb9jAXkjM/rcQLaDeGws/JMl2 njqquX61OqaVk6wcBf5ubyFTuib92ZmPuYgkP5kaZHdk3PAKH9bGvcbfsKrq5MRiolnb 7baaH0rj3M7UfjbbReRjyPh3rGAS6MPmCOcdAKLa1oQX3ITYEyNPQDyFkrcO43KMCKYb 98VxlsQsf0LSSXcyQ4+5Nf8LsZcFEreyUff/df3zKhMmDkLYo1m1rqPv2N82nN4YU6Sr 1t6A== X-Gm-Message-State: APt69E0D0hI9atP6LYyJjTkOgJ5eeR7C0D9GkCpZG+uI76qm6I2//yNh WXMD1KsVPhlEhYPkOdtGPJY= X-Google-Smtp-Source: ADUXVKJ76pkbBPPIf/Os9vP90LcMiKZPGq4+bqh7WqcMJmOc1HLYVxk/IdsZcWqBCRdgDV9LPN+Gng== X-Received: by 2002:a50:f534:: with SMTP id t49-v6mr3465114edm.42.1528998762844; Thu, 14 Jun 2018 10:52:42 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1006? ([2600:8802:5600:1546::1006]) by smtp.gmail.com with ESMTPSA id c11-v6sm2737334eda.64.2018.06.14.10.52.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 10:52:41 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0CEF676A-33F0-4DB5-B162-5F95554CE377"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 14 Jun 2018 10:52:38 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Alexandre Petrescu References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 17:52:48 -0000 --Apple-Mail=_0CEF676A-33F0-4DB5-B162-5F95554CE377 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the record, I don't think the subject of registering for IETF = meetings, hotel choice, using PayPal, and using Github is covered in the = IPv6 charter. Yes, I'd like PayPal, Github, and a variety of other web = sites to implement IPv6. I'm pretty sure their maintainers are not = reading this list. > On Jun 13, 2018, at 5:47 AM, Alexandre Petrescu = wrote: >=20 > When going to IETF meetings, one is concerned about which hotel to = book. Typically the concerns are the price range, distance from IETF = venue, transportation, comfort conditions, WiFi, breakfast, rating by = others, etc. >=20 > One other interesting criterion is whether the reservation with the = link provided by IETF can be made on IPv6, or not. >=20 > For IETF 102 > Fairmont the Queen Elizabeth: IPv6 reservation ok > Le Centre Sheraton: IPv6 reservation not possible > others... >=20 > Alex >=20 > Le 13/06/2018 =C3=A0 11:20, Alexandre Petrescu a =C3=A9crit : >> Le 27/04/2018 =C3=A0 05:12, Jen Linkova a =C3=A9crit : >>> On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu >>> wrote: >>>> Even us, at IETF, whenever we write a new hot Internet Draft we put = it >>>> on an IPv4 website first. >>> Actually we we don't. >>>=20 >>>> (I guess datatracker is not reachable on IPv6, >>>> just guess.) >>>=20 >>> I've just completely disabled IPv4 on my workstation and >>> https://datatracker.ietf.org works just fine (I tested browsing the >>> drafts and some links on WG Chair dashboard). >> I have just used an IPv6 linux laptop on an IPv6 cellular link that = gives no IPv4. >> The laptop connects ok to https://ietf.org, tools.ietf.org. I have = even tried to register for the next meeting. I went with the process up = to filling the data, but stopped there. >> There are however some websites that dont work, like github.com. = Many people use github for IETF work like drafts, charters, etc. >> Alex >> _______________________________________________ >> 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 --Apple-Mail=_0CEF676A-33F0-4DB5-B162-5F95554CE377 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+AFAlsiq2cACgkQEhdRnd2G P+CrRg/9Grjn2EqTVnFFpo0l67FP+Z6l7LvbtvZasekQ+e2hesGH/eioVvEOnp7d W9Ite8aobee64cv4ek3Ca678QofqcoJCd0ENXXxd6gewFsJNt4WcPO6sHxT90R9P A9JVYndXwukDqKCI5CiA+u8dIamvp8QbexYA4WdoJUT0/Eipn7TC18AvD3hvvcxW 9gfjOzIuSOwvYGjGcGY7rdbLXsY2GCnt/L1O9uePrjnCvUIsUJ6s7oouBwCHccuY AxxStOKpGFaqoCjKg39j2O/7TlTWwP0aSn9FuUfb5hYH6J2zjKGQUndbnixR6bsF kEAV95kHaX2qy15DlqsaN2pg0nGppLHuDnicg1ArNjg+NmfuiQYziUj6c3fG4HGO 8GKUr0JjccEvJ3bSiZqvnyF+1ccDWAJMdGxL7GhvrlrCKDxlSGxQB/rD0eC5zJ+n 07063Y7v03OpJfg0R9foWB9TKte5XuZur+BlIw+Xf5O4YYTx3ugS0iGWW2ap4m5x x/Pl1ls0OO9RsMefvHMhbqSwyxt6a9T0vKpsX9Hlz3S8HtkMQLUiUj0h8Hcib/mF NJgzPE2U5ILvzNziWCRXS4y4S0u0GnLoIcwhrUzzF3Ji3902VhIWYBX+y2bkAzjo AugloeoaHN58n0f2b8poaGMkG3yENzk65NIErfd6W13uVozFgAM= =VBHq -----END PGP SIGNATURE----- --Apple-Mail=_0CEF676A-33F0-4DB5-B162-5F95554CE377-- From nobody Thu Jun 14 13:15: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 955A8130E98 for ; Thu, 14 Jun 2018 13:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mA7eM3telifR for ; Thu, 14 Jun 2018 13:15:31 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4756130E70 for ; Thu, 14 Jun 2018 13:15:30 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-41-164.kabelnet.hu [79.121.41.164]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5EKFLAd025236 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 14 Jun 2018 22:15:27 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-164.kabelnet.hu [79.121.41.164] claimed to be [192.168.1.114] To: v6ops@ietf.org References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Thu, 14 Jun 2018 22:15:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.164; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 20:15:34 -0000 Hello Jordi, I am happy with this outcome. :-) I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.) What do you think of it? Best regards, Gbor 6/14/2018 6:21 PM keltezssel, JORDI PALET MARTINEZ rta: > Hi all, > > > > After a long chat with the authors of RFC8026, we have found an alternative solution which avoids updating RFC8026 and also avoids requiring a new option code for 464XLAT, as there is already one that we can use, which is related to NAT64, so still can use RFC8026 for our original intend of prioritizing and managing the available mechanism from the operator network. > > > > Consequently, we are working in a new version of draft-ietf-v6ops-transition-ipv4aas, which will be posted ASAP in v6ops. > > > > Anyway, we had lot of fun in v6ops because this, and I think every comment has been very useful! > > > > Thanks! > > > > Regards, > > Jordi > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 14 13:42: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 98CCB130EEF for ; Thu, 14 Jun 2018 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h0HlHyKVcwz for ; Thu, 14 Jun 2018 13:42:53 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D784130E6E for ; Thu, 14 Jun 2018 13:42:53 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v16-v6so131661wmh.5 for ; Thu, 14 Jun 2018 13:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Uyuht2y/rzFG0uAA89nAeBwJ4oYXuw1/Ll3SYMjmmrg=; b=DYZOwqz4pbkkpN7DrJZbcmJbdtEHtxTBS9pr+A8V6sfBeF6jgd1VqgzOAV84AjpqJK rV0exkao9rtYuHB5fVyerMUi5gwe8pM3VrySeGMT2tfJZ+H9/03Z9SBUuF1EOEVki/Sh maue7vym+0CNkNYdMvDhQG6JhlS/7G8o3y1D6eBV1E+yezQ1Km5crgtsHNKDPRC9uDMx 0z1OIRHk0Fv+uBVZuq9oStQrZUMlxIA793SJ65+eEf+2mp89wFvt6ik2A934E64jGUrA wWhSUIaZAfeVK9yc7jZ9k2HKXRtwQAECyH8APdwwhMCT+tcDhEbed+JZb37ligpeDlue BfqQ== 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=Uyuht2y/rzFG0uAA89nAeBwJ4oYXuw1/Ll3SYMjmmrg=; b=rMoXBKRjz55tkZk4st7HbcijghLyCd8pmktbBFTS7i9CitiaIDm87zR06qoEZCSZCE s5uCdSFjWd2CPAO2lmCqj44kxH1m2ti79e0NblZ+nRhq9/PGnrZ6iuP76Ndy2re9xtXW dKFOMJF9O2AtyV0K0aKUaSS4rfrOetjg2l1sAtNdSZl8iJxzaIuw9J0OHbZkzL09PIWS hUCCTWCxs8058kbcvMoVVkVqjPt/ZVr5CyzoCDeQmTnZo4YY/s9soPcs86CcvLt7pFJU VRVtxDF5nWkgivuoIIm4ls7ohFfSo1k+AsKrmGODo7EKlzxfhZBd4OaONhQAzUACXtvb GyBQ== X-Gm-Message-State: APt69E1IGPEU48oHjCgfFxPjxETZsHnShSd63fDYb91MvANHYJphSssI Q3cc2jlcuuCAhiKwJYiIK2qTJcPw X-Google-Smtp-Source: ADUXVKJbRNmk40HGIpPaG+TinLTj7SPZRzUy6bCQEmADhUHcf02E1dvGrLeC3bpMeUGIo5G+vvg7ww== X-Received: by 2002:a50:8c41:: with SMTP id p59-v6mr3855455edp.207.1529008972165; Thu, 14 Jun 2018 13:42:52 -0700 (PDT) Received: from 247.66.20.149.in-addr.arpa (247.66.20.149.in-addr.arpa. [149.20.66.247]) by smtp.gmail.com with ESMTPSA id c40-v6sm2842913edb.68.2018.06.14.13.42.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 13:42:51 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5456B852-DCE1-4841-B9A1-242F7BB1D339"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 14 Jun 2018 13:42:47 -0700 In-Reply-To: Cc: v6ops@ietf.org To: =?utf-8?Q?Lencse_G=C3=A1bor?= References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 20:42:56 -0000 --Apple-Mail=_5456B852-DCE1-4841-B9A1-242F7BB1D339 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor = wrote: > I have an idea: perhaps you could add a section about the pros and = cons of each transition technology covered by the draft. (It could be = helpful for the network operators when selecting the technology matching = their need the best. However, I am not sure whether it is in the scope = of this draft.) It would be incredibly useful. That said, it often involves value = judgements, which are essentially in the eye of the beholder. We have had a recent thread regarding 464xlat and MAP-T. If I can say = this without actually putting words into Lorenzo's mouth, his issues = with translation in general are probably summarized in RFC 2993, and I = would agree with him. The distinction between 464xlat and MAP-T you'll = have to find in his emails; they are both services an ISP might deploy, = and while they use the same tool (translation) they are not the same = service. It seems to be generally agreed that MAP-T is more expensive to = deploy than 464xlat; the question is what the extra expense buys, and = whether someone agrees that the result is worth the cost. So in your proposed section, I would have to ask Jordi to not only say = "MAP-T costs more to deploy than 464xlat", but gives the argument that = might lead someone to choose MAP-T. And then we get to the large variety of other technologies, some of = which presume an IPv4 core network and some an IPv6 core network (and = none of which assume an MPLS core network carrying both kinds of = traffic). If you would like to write such a document, please be my guest, by all = means. But I'm not going to expect Jordi to do all that in the coming = two weeks... --Apple-Mail=_5456B852-DCE1-4841-B9A1-242F7BB1D339 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+AFAlsi00cACgkQEhdRnd2G P+ABWxAAk38avRovHOiBcmYSUrRjg1moJUM6yVP1h3qgieqcQJKzI3Wwj273NePF JZlAu+6DHRmkrsDGoC+agtoM9+pvtd+BcHV7buTqhGDi98l47nDd9SGE9sXKx0/Y fzMqXJ15Yb2xbeaE6fo/b0sEMHcrDCl2w+V4bFpgoFBMg2A8c/86uDnB5j7dFv0w 58BnQNZC0JaPty5e9npiiphOpA070IkHmZCKUVZhKlBlcBGzAAXUrWc1t1begXny tq+y4TRNzPJd3vlnBdci3ueGAl2F3DFg+/iZaopgdi115PDinvjShMB2JMewtFgy hyjKMbuBETFA4kX7WkOOU+RNK0hbQtiI+F9q9YsE7BG0i2x2K5avKputfoJQJ4dK 2yVD6rtAqCxEcFNHEWgkQKHxN/hhudzmJWjz5na6rC01jbhnw8TMr4JXqYEMIWvl KtoHljNFCaolLmwQlKh+NtDdXXUX7yEvuVpa2A/p6V+30j+G3q9ya77P5jacPqcF r8scw8y2LRVcGooMXaNSs7w71+OO6SqHgTjYNxziDo1giJYzxHQoPBkGbeT2Uu2d RvDZf1DHYTw4BVYB02FUIV4GTaFoC4Fzm+KFwxZFYp8zxinILWmV7vTJxp9aeQwC po84rX0DP7qo48yscS6+nQzM2mBlivtQ6wP771tFjECVrnLh2Z8= =TFmd -----END PGP SIGNATURE----- --Apple-Mail=_5456B852-DCE1-4841-B9A1-242F7BB1D339-- From nobody Thu Jun 14 14:38: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 6C262130E5A for ; Thu, 14 Jun 2018 14:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er5cb1V2-JJi for ; Thu, 14 Jun 2018 14:38:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C88212D949 for ; Thu, 14 Jun 2018 14:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529012289; x=1529617089; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=QRCU98t0 P1LbXOreJ1npNugLey7RiUlm2WQLJzcLhvk=; b=xJo4DoIZrb5651KZa7ORrW7R 3v2/jr05O7USWKTM9B3I+fV9uC4yx340cIxxhmLm1++ssV9/+P48thztl+FyK4Zu LRp3QIvyUj7pJmzMrxwytDkX5iYOwzONIfMNi4xHYdO1QxxmGifG8ALpkbLGdv5+ bSulSTjUpbLxbMASEW0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 23:38:09 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 23:38:09 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789622.msg for ; Thu, 14 Jun 2018 23:38:08 +0200 X-MDRemoteIP: 2001:470:1f09:495:7423:82f3:bd2f:70bb X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 23:38:08 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 14 Jun 2018 23:38:04 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: <4B61E92B-96D6-4051-B437-FA5E9AAA6905@consulintel.es> Thread-Topic: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 21:38:15 -0000 Not in scope, and I think that will make this draft an endless discussion. Sometimes is not black and white, so I don't think the IETF can suggest one= or other mechanism. Pros and cons maybe, but at the end many pros and cons= need to be "balanced" in each network. I've a presentation that do that and I even try to score each possible aspe= ct of the transitions mechanisms, their impact in the network, etc., in an = excel spreadsheet, but I always explicitly say "you really need to check th= is against your own case" ... That said, I'm happy, once we are done with this draft, to start that work = if the WG believe is useful. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Lencse G=C3=A1bor Fecha: jueves, 14 de junio de 2018, 22:16 Para: Asunto: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transitio= n-ipv4aas Hello Jordi, =20 I am happy with this outcome. :-) =20 I have an idea: perhaps you could add a section about the pros and cons= =20 of each transition technology covered by the draft. (It could be helpfu= l=20 for the network operators when selecting the technology matching their= =20 need the best. However, I am not sure whether it is in the scope of thi= s=20 draft.) =20 What do you think of it? =20 Best regards, =20 G=C3=A1bor =20 6/14/2018 6:21 PM keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta: > Hi all, > > > > After a long chat with the authors of RFC8026, we have found an alter= native solution which avoids updating RFC8026 and also avoids requiring a n= ew option code for 464XLAT, as there is already one that we can use, which = is related to NAT64, so still can use RFC8026 for our original intend of pr= ioritizing and managing the available mechanism from the operator network. > > > > Consequently, we are working in a new version of draft-ietf-v6ops-tra= nsition-ipv4aas, which will be posted ASAP in v6ops. > > > > Anyway, we had lot of fun in v6ops because this, and I think every co= mment has been very useful! > > > > Thanks! > > > > Regards, > > Jordi > > =20 > > =20 > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > 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 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 14 14:49: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 44AA8130E5A for ; Thu, 14 Jun 2018 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjNg88OmwnB5 for ; Thu, 14 Jun 2018 14:49:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A547912D949 for ; Thu, 14 Jun 2018 14:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529012985; x=1529617785; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=P3OpmmPdLnBORjdhTgU6uEVgNhKdJxbeXN9GlrC7ubU=; b=bzwkn2BUoSLgW 3iqCIjKGMsrxoUaiqOB4r6RKXMOZmFpq6K73Mst2jz/WascrWTOP+WZgVrfmdjgk FWqgGwzVjTwGIXl5i93Z0J+oy/S+JXzUkyMb2XO8ToNQL7To/ORYWiFqMSyl+KVH aXVWQSZN8Rn7fGnT+KRX3gYu+fGTaA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 14 Jun 2018 23:49:45 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 14 Jun 2018 23:49:45 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789628.msg for ; Thu, 14 Jun 2018 23:49:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:7423:82f3:bd2f:70bb X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 14 Jun 2018 23:49:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 14 Jun 2018 23:49:39 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , Lencse =?UTF-8?B?R8OhYm9y?= CC: Message-ID: Thread-Topic: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 21:49:51 -0000 If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks... Fred, I'm easy to challenge ! But to be honest, prefer to concentrate the next two weeks in having people contributing to the actual document, and the NAT64 one. In addition to that, I really thing mixing Gabor suggestion in this document will not be so useful at this stage and will break our original idea of making it as something to follow for CE vendors as RFC7084 (not operators). But really, I'm happy to take that afterwards. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Thu Jun 14 15:17: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 58AB8130F6F for ; Thu, 14 Jun 2018 15:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWGW26W5IbwF for ; Thu, 14 Jun 2018 15:17:02 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92994130E61 for ; Thu, 14 Jun 2018 15:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529014619; x=1529619419; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=TsWjIVZI0xRaZUZvzp+h+Ro43raLPCYnqh3uMT+5xeY=; b=Czh2e3fCNI/O2 vwP4OK0P+xF0/5+Bql0Vpff5c1PUQ5fxIu/8hLhm9ekKeMUnkNBrea9GC3dXtTjf 13Sg6A1Dulg9frhY83jIh9TFg47QyMLvI3ZfA1zqe+J2aZgzybiqsvjyli56HfYs TmnUUOY1iiXg2eXkI9XHteGBc92WKs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 15 Jun 2018 00:16:59 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 15 Jun 2018 00:16:59 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005789635.msg for ; Fri, 15 Jun 2018 00:16:57 +0200 X-MDRemoteIP: 2001:470:1f09:495:7423:82f3:bd2f:70bb X-MDHelo: [10.10.10.129] X-MDArrival-Date: Fri, 15 Jun 2018 00:16:57 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1703d38c4a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 15 Jun 2018 00:16:55 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , Lencse =?UTF-8?B?R8OhYm9y?= CC: Message-ID: <3F757F27-AA76-4153-BE18-61CC2B93868E@consulintel.es> Thread-Topic: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 22:17:05 -0000 Here is a link to that table (I just twitted it): https://twitter.com/jordipalet/status/1007383535471222784 Is easy to understand how it works. Depending on each "feature impact or re= levance" in your network you use red, orange or green (as a traffic light),= and each color has a value (red 0, orange 0.5, green 1). Of course, it is only an idea, and really depends on each network and how y= ou value each "feature" (so the scoring could be adapted based on each netw= ork case). ASAP I've a minute, I will try to add (if not already there) all the inputs= that we have got in the list this week, but not just for MAP/464XLAT, for = every mechanism. To make it correctly in a draft, we will need to agree what it means each l= ine. For example, "scalability" in what sense ? Is not so easy ... just rec= all when I wrote the draft about what it means "IPv6-only" ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Fecha: jueves, 14 de junio de 2018, 23:50 Para: Fred Baker , Lencse G=C3=A1bor CC: Asunto: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transitio= n-ipv4aas If you would like to write such a document, please be my guest, by all= means. But I'm not going to expect Jordi to do all that in the coming two = weeks... =20 =20 =20 Fred, =20 =20 =20 I'm easy to challenge ! But to be honest, prefer to concentrate the nex= t two weeks in having people contributing to the actual document, and the N= AT64 one. =20 =20 =20 In addition to that, I really thing mixing Gabor suggestion in this doc= ument will not be so useful at this stage and will break our original idea = of making it as something to follow for CE vendors as RFC7084 (not operator= s). =20 =20 =20 But really, I'm happy to take that afterwards. =20 =20 =20 _______________________________________________ =20 v6ops mailing list =20 v6ops@ietf.org =20 https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 14 18:38: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 6D4C0130DD7 for ; Thu, 14 Jun 2018 18:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kpVra4o_N7X for ; Thu, 14 Jun 2018 18:38:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3112E039 for ; Thu, 14 Jun 2018 18:38:31 -0700 (PDT) Received: from [192.168.2.4] (static.vnpt.vn [113.185.22.114] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id w5F1Z0xr007183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2018 18:35:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=default; t=1529026509; bh=xgQ2CGDTgpsPrx9UeauI1mIMbKJtmrjvPEwUYRcfmnk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=THrGIRnBqaLBA+zB4S8xAHWck5ntsYlTKA8gZpSbYigonWMZgD/52IJGveBZYxEAD fUuWCKkfpKoHWW/dC20gwoaINaYfketw/nRjIZevUOA0nD0lMswPojrprjO/MYpvSG ZsczLaHllOsGa90HarqG1FbMOWHTZgc470R0dYpQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (15F79) In-Reply-To: <4B61E92B-96D6-4051-B437-FA5E9AAA6905@consulintel.es> Date: Fri, 15 Jun 2018 08:34:57 +0700 Cc: =?utf-8?Q?Lencse_G=C3=A1bor?= , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <84F01B91-80A6-48EB-8D26-E95B25E411EE@delong.com> References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <4B61E92B-96D6-4051-B437-FA5E9AAA6905@consulintel.es> To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 01:38:34 -0000 I agree with Jordi. Not in scope.=20 This would make a fine white paper to publish somewhere, but IMHO, it=E2=80=99= s certainly out of scope for this document, likely to be a fruitless flame w= ar in this particular group.=20 To be a useful white paper, I believe it should cover as many of the potenti= ally useful (by the broadest definition of at least a few cases where the so= lution is in use exist) options and cover the facts, advantages, and trade o= ffs of each one. It should not recommend any solution, but should provide a c= oncise comparison allowing the reader to make an informed decision about wha= t best fits their particular use case.=20 While I think some members of this group could do an excellent job authoring= such a paper, I do not believe it would likely survive the holy war that wo= uld ensue if it were a group project.=20 Owen Owen > On Jun 15, 2018, at 04:38, JORDI PALET MARTINEZ wrote: >=20 > Not in scope, and I think that will make this draft an endless discussion.= >=20 >=20 >=20 > Sometimes is not black and white, so I don't think the IETF can suggest on= e or other mechanism. Pros and cons maybe, but at the end many pros and cons= need to be "balanced" in each network. >=20 >=20 >=20 > I've a presentation that do that and I even try to score each possible asp= ect of the transitions mechanisms, their impact in the network, etc., in an e= xcel spreadsheet, but I always explicitly say "you really need to check this= against your own case" ... >=20 >=20 >=20 > That said, I'm happy, once we are done with this draft, to start that work= if the WG believe is useful. >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de Lencse G=C3=A1bor >=20 > Fecha: jueves, 14 de junio de 2018, 22:16 >=20 > Para: >=20 > Asunto: Re: [v6ops] no need to update RFC8026 in draft-ietf-v6ops-transiti= on-ipv4aas >=20 >=20 >=20 > Hello Jordi, >=20 >=20 >=20 > I am happy with this outcome. :-) >=20 >=20 >=20 > I have an idea: perhaps you could add a section about the pros and cons= =20 >=20 > of each transition technology covered by the draft. (It could be helpfu= l=20 >=20 > for the network operators when selecting the technology matching their=20= >=20 > need the best. However, I am not sure whether it is in the scope of thi= s=20 >=20 > draft.) >=20 >=20 >=20 > What do you think of it? >=20 >=20 >=20 > Best regards, >=20 >=20 >=20 > G=C3=A1bor >=20 >=20 >=20 > 6/14/2018 6:21 PM keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta: >=20 >> Hi all, >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> After a long chat with the authors of RFC8026, we have found an alternati= ve solution which avoids updating RFC8026 and also avoids requiring a new op= tion code for 464XLAT, as there is already one that we can use, which is rel= ated to NAT64, so still can use RFC8026 for our original intend of prioritiz= ing and managing the available mechanism from the operator network. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Consequently, we are working in a new version of draft-ietf-v6ops-transit= ion-ipv4aas, which will be posted ASAP in v6ops. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Anyway, we had lot of fun in v6ops because this, and I think every commen= t has been very useful! >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Thanks! >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Regards, >=20 >>=20 >=20 >> Jordi >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> ********************************************** >=20 >> IPv4 is over >=20 >> Are you ready for the new Internet ? >=20 >> http://www.consulintel.es >=20 >> The IPv6 Company >=20 >>=20 >=20 >> This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> _______________________________________________ >=20 >> v6ops mailing list >=20 >> v6ops@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 15 02:11: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 C7F6F12F1AC for ; Fri, 15 Jun 2018 02:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tJX5ZQDM9JG for ; Fri, 15 Jun 2018 02:10:58 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B7312F1A2 for ; Fri, 15 Jun 2018 02:10:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F9Auea041287; Fri, 15 Jun 2018 11:10:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A71C62049BC; Fri, 15 Jun 2018 11:10:56 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9933E2049BA; Fri, 15 Jun 2018 11:10:56 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F9Au64014390; Fri, 15 Jun 2018 11:10:56 +0200 To: Fred Baker Cc: v6ops@ietf.org References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> <12796_1528998773_5B22AB74_12796_5985_1_E57F679B-6E08-4DFE-98A7-88D2962E3044@gmail.com> From: Alexandru Petrescu Message-ID: <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> Date: Fri, 15 Jun 2018 11:10:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <12796_1528998773_5B22AB74_12796_5985_1_E57F679B-6E08-4DFE-98A7-88D2962E3044@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:11:02 -0000 Le 14/06/2018 à 19:52, Fred Baker a écrit : [...] > For the record, I don't think the subject of registering for IETF > meetings, hotel choice, using PayPal, and using Github is covered in > the IPv6 charter. I agree with you. But if we wanted to work on that Charter by only using IPv6 technology then we would have great success, only with a few quirks: paypal, hotel choice and github. That is a question of _using_ IPv6 technology. There are many ways to try the use of IPv6 technology. One great way is to try the use of the IPv6 technology while we are at an IETF meeting. They offer some ESSID that does only IPv6. I did that and it is a great testing. However, while doing that test on ESSID that is IPv6 only I felt that other tests were needed from elsewhere than IETF. Because we were already at IETF, but there is a need to come to IETF first. So now, before coming at IETF, is a great time to test IPv6. To answer the question: how IPv6 can help to come to IETF? Or how IPv6 is a break in coming to IETF? > Yes, I'd like PayPal, Github, and a variety of > other web sites to implement IPv6. I'm pretty sure their maintainers > are not reading this list. Well, I can pick one. The github. What is the postmaster address at github? I can write her an email. (I want to complain to her not only about IPv6, but also about their storage format: they break UTF-8, and as such people's names get wrong in drafts; examples available upon request). Alex > >> On Jun 13, 2018, at 5:47 AM, Alexandre Petrescu >> wrote: >> >> When going to IETF meetings, one is concerned about which hotel to >> book. Typically the concerns are the price range, distance from >> IETF venue, transportation, comfort conditions, WiFi, breakfast, >> rating by others, etc. >> >> One other interesting criterion is whether the reservation with the >> link provided by IETF can be made on IPv6, or not. >> >> For IETF 102 Fairmont the Queen Elizabeth: IPv6 reservation ok Le >> Centre Sheraton: IPv6 reservation not possible others... >> >> Alex >> >> Le 13/06/2018 à 11:20, Alexandre Petrescu a écrit : >>> Le 27/04/2018 à 05:12, Jen Linkova a écrit : >>>> On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu >>>> wrote: >>>>> Even us, at IETF, whenever we write a new hot Internet Draft >>>>> we put it on an IPv4 website first. >>>> Actually we we don't. >>>> >>>>> (I guess datatracker is not reachable on IPv6, just guess.) >>>> >>>> I've just completely disabled IPv4 on my workstation and >>>> https://datatracker.ietf.org works just fine (I tested browsing >>>> the drafts and some links on WG Chair dashboard). >>> I have just used an IPv6 linux laptop on an IPv6 cellular link >>> that gives no IPv4. The laptop connects ok to https://ietf.org, >>> tools.ietf.org. I have even tried to register for the next >>> meeting. I went with the process up to filling the data, but >>> stopped there. There are however some websites that dont work, >>> like github.com. Many people use github for IETF work like >>> drafts, charters, etc. Alex >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jun 15 02:31: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 7347B126DBF for ; Fri, 15 Jun 2018 02:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsNsJ6bCr504 for ; Fri, 15 Jun 2018 02:31:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017E5120049 for ; Fri, 15 Jun 2018 02:31:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F9VgH7001469 for ; Fri, 15 Jun 2018 11:31:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 226A42049DD for ; Fri, 15 Jun 2018 11:31:42 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 185DC20497D for ; Fri, 15 Jun 2018 11:31:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5F9Vfq5028780 for ; Fri, 15 Jun 2018 11:31:42 +0200 To: v6ops@ietf.org References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> <12796_1528998773_5B22AB74_12796_5985_1_E57F679B-6E08-4DFE-98A7-88D2962E3044@gmail.com> <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> From: Alexandre Petrescu Message-ID: <78bc2ac9-c15e-c5bb-87a9-ac7ab4f3d7f0@gmail.com> Date: Fri, 15 Jun 2018 11:31:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:31:47 -0000 Le 15/06/2018 à 11:10, Alexandru Petrescu a écrit : > > > Le 14/06/2018 à 19:52, Fred Baker a écrit : > [...] > >> For the record, I don't think the subject of registering for IETF >> meetings, hotel choice, using PayPal, and using Github is covered in >> the IPv6 charter. > > I agree with you. > > But if we wanted to work on that Charter by only using IPv6 technology > then we would have great success, only with a few quirks: paypal, hotel > choice and github. > > That is a question of _using_ IPv6 technology. > > There are many ways to try the use of IPv6 technology. > > One great way is to try the use of the IPv6 technology while we are at > an IETF meeting.  They offer some ESSID that does only IPv6.  I did that > and it is a great testing. I mean I did some testing. The ESSID with IPv6 only was designed and deployed by IETF network designers. Alex > > However, while doing that test on ESSID that is IPv6 only I felt that > other tests were needed from elsewhere than IETF.  Because we were > already at IETF, but there is a need to come to IETF first. > > So now, before coming at IETF, is a great time to test IPv6.  To answer > the question: how IPv6 can help to come to IETF?  Or how IPv6 is a break > in coming to IETF? > >> Yes, I'd like PayPal, Github, and a variety of >> other web sites to implement IPv6. I'm pretty sure their maintainers >> are not reading this list. > > Well, I can pick one.  The github.  What is the postmaster address at > github?  I can write her an email. > > (I want to complain to her not only about IPv6, but also about their > storage format: they break UTF-8, and as such people's names get wrong > in drafts; examples available upon request). > > Alex > >> >>> On Jun 13, 2018, at 5:47 AM, Alexandre Petrescu >>> wrote: >>> >>> When going to IETF meetings, one is concerned about which hotel to >>> book.  Typically the concerns are the price range, distance from >>> IETF venue, transportation, comfort conditions, WiFi, breakfast, >>> rating by others, etc. >>> >>> One other interesting criterion is whether the reservation with the >>> link provided by IETF can be made on IPv6, or not. >>> >>> For IETF 102 Fairmont the Queen Elizabeth: IPv6 reservation ok Le >>> Centre Sheraton: IPv6 reservation not possible others... >>> >>> Alex >>> >>> Le 13/06/2018 à 11:20, Alexandre Petrescu a écrit : >>>> Le 27/04/2018 à 05:12, Jen Linkova a écrit : >>>>> On Thu, Apr 26, 2018 at 6:42 PM, Alexandre Petrescu >>>>> wrote: >>>>>> Even us, at IETF, whenever we write a new hot Internet Draft >>>>>> we put it on an IPv4 website first. >>>>> Actually we we don't. >>>>> >>>>>> (I guess datatracker is not reachable on IPv6, just guess.) >>>>> >>>>> I've just completely disabled IPv4 on my workstation and >>>>> https://datatracker.ietf.org works just fine (I tested browsing >>>>> the drafts and some links on WG Chair dashboard). >>>> I have just used an IPv6 linux laptop on an IPv6 cellular link >>>> that gives no IPv4. The laptop connects ok to https://ietf.org, >>>> tools.ietf.org.  I have even tried to register for the next >>>> meeting.  I went with the process up to filling the data, but >>>> stopped there. There are however some websites that dont work, >>>> like github.com.  Many people use github for IETF work like >>>> drafts, charters, etc. Alex >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 15 05:24: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 C5FD4130E86 for ; Fri, 15 Jun 2018 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmS8azMKvsEL for ; Fri, 15 Jun 2018 05:24:16 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1AA130E14 for ; Fri, 15 Jun 2018 05:24:15 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-41-164.kabelnet.hu [79.121.41.164]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5FCO3xS042744 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Jun 2018 14:24:09 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-164.kabelnet.hu [79.121.41.164] claimed to be [192.168.1.114] To: Fred Baker References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Cc: v6ops@ietf.org Message-ID: <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> Date: Fri, 15 Jun 2018 14:23:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------44737A3D092058A04CCA14B2" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.164; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:24:23 -0000 This is a multi-part message in MIME format. --------------44737A3D092058A04CCA14B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Fred, Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'. I have several questions. 1. Depth of the analysis - Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. - Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219. What depth do you recommend? 2. Method for getting the results and their publication As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions. After commenting and discussing, I would compile it to an I-D. Do you think that v6ops WG would finally agree to publish it as an RFC? As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D. What do you think of it? 3. Timeline I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103. The further parts would require much more time and results could be included gradually in 1-2 years. 4. Scope The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6. IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4]. One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests. Thus, the scope can be widened, if you would like to. What do you think about my recommendations? Best regards, Gábor References: [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 [2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", /IEICE Transactions on Communications/, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007 [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", /Computer Communications/ (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004 [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", /Computer Communications/ (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 6/14/2018 10:42 PM keltezéssel, Fred Baker írta: > > On Jun 14, 2018, at 1:15 PM, Lencse Gábor wrote: >> I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.) > It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder. > > We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost. > > So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T. > > And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic). > > If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks... --------------44737A3D092058A04CCA14B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear Fred,

Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'.

I have several questions.

1. Depth of the analysis

- Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219.

What depth do you recommend?

2. Method for getting the results and their publication

As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions.
After commenting and discussing, I would compile it to an I-D.

Do you think that v6ops WG would finally agree to publish it as an RFC?

As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D.

What do you think of it?

3. Timeline

I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103.

The further parts would require much more time and results could be included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.

IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4].
One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests.

Thus, the scope can be widened, if you would like to.

What do you think about my recommendations?

Best regards,

Gábor

References:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007

[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005


6/14/2018 10:42 PM keltezéssel, Fred Baker írta:

On Jun 14, 2018, at 1:15 PM, Lencse Gábor <lencse@hit.bme.hu> wrote:

I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.)

It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder.

We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost.

So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T.

And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic).

If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks...

--------------44737A3D092058A04CCA14B2-- From nobody Fri Jun 15 07:04: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 85D2B126CC7 for ; Fri, 15 Jun 2018 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ostI1jeTKJ-X for ; Fri, 15 Jun 2018 07:04:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FCD1294D7 for ; Fri, 15 Jun 2018 07:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529071480; x=1529676280; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=JUZBjJlyObhHTGk8Y361Ld sPNJ2WIeQ6OEvqreFkVHw=; b=n6NNCT3f5DLYQMq+n2YmorTOSPv5U/bcDpm3ym FDqvgs6BcuSUoL/JZ1Gfk+mErsyZzFTxPn0YXkX7O8zUjvNTIrwwIVoNkA+RjpUI 4sRbhUdoJYgBNTwXkWbCi0+2GFBjHAUmBAzFkk4GPB5UGXgCrMSTI+ytNySFZEqp 03W2M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 15 Jun 2018 16:04:40 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 15 Jun 2018 16:04:39 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005790085.msg for ; Fri, 15 Jun 2018 16:04:37 +0200 X-MDRemoteIP: 2001:470:1f09:495:bc41:eb97:da67:6671 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Fri, 15 Jun 2018 16:04:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1704c2357c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 15 Jun 2018 16:04:37 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Fred Baker CC: Message-ID: <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> Thread-Topic: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> In-Reply-To: <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611923477_965610706" Archived-At: Subject: Re: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 14:04:48 -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_3611923477_965610706 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m not sure it makes sense something that is not published in, let= =E2=80=99s say, maximum one year from now. =20 Anyway, I=E2=80=99m happy to help. =20 By the way, I got some private questions about this =E2=80=A6 The table tha= t I=E2=80=99ve posted yesterday, was developed about 3 years ago, and I=E2= =80=99ve not updated it since them. Actually from emails exchanged today, I= discovered a couple of mistakes and also things that can be improved, so i= f needed I can update it as well. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: viernes, 15 de junio de 2018, 14:25 Para: Fred Baker CC: Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -= - Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas =20 Dear Fred, Thank you very much for your invitation. I am willing to accept it, but I w= ould like to clarify your expectations before saying 'yes'. I have several questions. 1. Depth of the analysis - Basic level: well-known advantages and disadvantages, similarly as people= wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. - Advanced level: basic level + security analysis using the methodology def= ined in [1] + performance analysis according to RFC 8219. What depth do you recommend? 2. Method for getting the results and their publication As for the information for the basic level, I would prepare a google docs t= able, fill in the information I have and send the link to the v6ops list as= king contributions. After commenting and discussing, I would compile it to an I-D.=20 Do you think that v6ops WG would finally agree to publish it as an RFC? As for the information for the advanced level, I would work together with m= y students and PhD students, and publish our results first in academic pape= rs and then include their most important lessons into the I-D. What do you think of it? 3. Timeline I think that I could put together the first table in a few weeks. The contr= ibution of the v6ops list members and the discussion could be done in a few= months and then I could compile the results into an I-D in a few weeks. Pe= rhaps, it could be presented at IETF 103. The further parts would require much more time and results could be include= d gradually in 1-2 years. 4. Scope The smallest natural scope includes the technologies for IPv4AAS, that is: = 464XLAT, DS-Lite, MAP-T/E and lw4o6. IPv6 transition technologies for other carefully selected scenarios might a= lso be included. E.g. I have significant amount of results in benchmarking = DNS64 servers, having a testing tool [2], a well defined methodology [3] an= d ready to use results concerning the DNS64 performance of BIND, PowerDNS a= nd Unbound [4].=20 One of my PhD students is currently benchmarking some sateless NAT64 implem= entations according the the dual DUT setup of RFC 8219 using an RFC 2544 co= mpatible Tester. Another PhD student is currently working on a RFC 8219 com= pliant NAT64 tester program (using DPDK) to be able to perform single DUT s= etup NAT64 benchmarking tests.=20 Thus, the scope can be widened, if you would like to. What do you think about my recommendations? Best regards, G=C3=A1bor References: [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of po= tential security issues of different IPv6 transition technologies: Threat a= nalysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol.= 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 [2] G. Lencse, D. Bakai, "Design and implementation of a test program for b= enchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100= -B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007 [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology = for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp= . 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004 [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theo= ry and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. = 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker =C3=ADrta: =20 On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor wrote: I have an idea: perhaps you could add a section about the pros and cons of = each transition technology covered by the draft. (It could be helpful for t= he network operators when selecting the technology matching their need the = best. However, I am not sure whether it is in the scope of this draft.) It would be incredibly useful. That said, it often involves value judgement= s, which are essentially in the eye of the beholder. =20 We have had a recent thread regarding 464xlat and MAP-T. If I can say this = without actually putting words into Lorenzo's mouth, his issues with transl= ation in general are probably summarized in RFC 2993, and I would agree wit= h him. The distinction between 464xlat and MAP-T you'll have to find in his= emails; they are both services an ISP might deploy, and while they use the= same tool (translation) they are not the same service. It seems to be gene= rally agreed that MAP-T is more expensive to deploy than 464xlat; the quest= ion is what the extra expense buys, and whether someone agrees that the res= ult is worth the cost. =20 So in your proposed section, I would have to ask Jordi to not only say "MAP= -T costs more to deploy than 464xlat", but gives the argument that might le= ad someone to choose MAP-T. =20 And then we get to the large variety of other technologies, some of which p= resume an IPv4 core network and some an IPv6 core network (and none of whic= h assume an MPLS core network carrying both kinds of traffic). =20 If you would like to write such a document, please be my guest, by all mean= s. But I'm not going to expect Jordi to do all that in the coming two weeks= ... _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611923477_965610706 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I=E2=80=99m not sure it makes sense something that is not pub= lished in, let=E2=80=99s say, maximum one year from now.<= /p>

 

Anyway, I=E2=80=99m happy to help.<= /o:p>

 

By the way, I got some priv= ate questions about this =E2=80=A6 The table that I=E2=80=99ve posted yeste= rday, was developed about 3 years ago, and I=E2=80=99ve not updated it sinc= e them. Actually from emails exchanged today, I discovered a couple of mist= akes and also things that can be improved, so if needed I can update it as = well.


Regards,

Jordi

&= nbsp;

 

 =

De: v6ops <v6ops-bounces@ietf.org> en n= ombre de Lencse G=C3=A1bor <lencse@hit.bme.hu>
Fecha: viern= es, 15 de junio de 2018, 14:25
Para: Fred Baker <fredbaker.iet= f@gmail.com>
CC: <v6ops@ietf.org>
Asunto: [v6o= ps] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no nee= d to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

&nbs= p;

Dear Fred,

Tha= nk you very much for your invitation. I am willing to accept it, but I woul= d like to clarify your expectations before saying 'yes'.

I have seve= ral questions.

1. Depth of the analysis

- Basic level: well-k= nown advantages and disadvantages, similarly as people wrote about MAP-T/E = and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic l= evel + security analysis using the methodology defined in [1] + performance= analysis according to RFC 8219.

What depth do you recommend?
2. Method for getting the results and their publication

As for the = information for the basic level, I would prepare a google docs table, fill = in the information I have and send the link to the v6ops list asking contri= butions.
After commenting and discussing, I would compile it to an I-D. =

Do you think that v6ops WG would finally agree to publish it as an = RFC?

As for the information for the advanced level, I would work tog= ether with my students and PhD students, and publish our results first in a= cademic papers and then include their most important lessons into the I-D.<= br>
What do you think of it?

3. Timeline

I think that I co= uld put together the first table in a few weeks. The contribution of the v6= ops list members and the discussion could be done in a few months and then = I could compile the results into an I-D in a few weeks. Perhaps, it could b= e presented at IETF 103.

The further parts would require much more t= ime and results could be included gradually in 1-2 years.

4. Scope

The smallest natural = scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP= -T/E and lw4o6.

IPv6 transition technologies for other carefully sel= ected scenarios might also be included. E.g. I have significant amount of r= esults in benchmarking DNS64 servers, having a testing tool [2], a well def= ined methodology [3] and ready to use results concerning the DNS64 performa= nce of BIND, PowerDNS and Unbound [4].
One of my PhD students is curren= tly benchmarking some sateless NAT64 implementations according the the dual= DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD stu= dent is currently working on a RFC 8219 compliant NAT64 tester program (usi= ng DPDK) to be able to perform single DUT setup NAT64 benchmarking tests. <= br>
Thus, the scope can be widened, if you would like to.

What do= you think about my recommendations?

Best regards,

G=C3=A1bor=

References:

[1] G. Lencse and Y. Kadobayashi, "Methodol= ogy for the identification of potential security issues of different IPv6 t= ransition technologies: Threat analysis of DNS64 and stateful NAT64", = Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, Au= gust 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Baka= i, "Design and implementation of a test program for benchmarking DNS64= servers", IEICE Transactions on Communications, vol. E100-B, n= o. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007

[3] = G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology= for DNS64 Servers", Computer Communications (Elsevier), vol. 1= 09, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.00= 4

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Impleme= ntations: Theory and Practice", Computer Communications (Elsevi= er), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2= 018.05.005

6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker =C3=ADrta:

 
On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor <lencse@hit.bme.hu> wrote:
I have an idea: perhaps you could add a section abo=
ut the pros and cons of each transition technology covered by the draft. (I=
t could be helpful for the network operators when selecting the technology =
matching their need the best. However, I am not sure whether it is in the s=
cope of this draft.)
It would be incredibly useful. That said, it often involves value =
judgements, which are essentially in the eye of the beholder.
 
We have had a recent thread regarding 464xlat and MAP-T.=
 If I can say this without actually putting words into Lorenzo's mouth, his=
 issues with translation in general are probably summarized in RFC 2993, an=
d I would agree with him. The distinction between 464xlat and MAP-T you'll =
have to find in his emails; they are both services an ISP might deploy, and=
 while they use the same tool (translation) they are not the same service. =
It seems to be generally agreed that MAP-T is more expensive to deploy than=
 464xlat; the question is what the extra expense buys, and whether someone =
agrees that the result is worth the cost.
 
S=
o in your proposed section, I would have to ask Jordi to not only say "=
;MAP-T costs more to deploy than 464xlat", but gives the argument that=
 might lead someone to choose MAP-T.
 
And then we get to=
 the large variety of other technologies, some of which presume an IPv4 cor=
e network and some an IPv6 core network (and none of which assume an MPLS c=
ore network carrying both kinds of traffic).
 
If you would like to write such a document, please be my guest, by all me=
ans. But I'm not going to expect Jordi to do all that in the coming two wee=
ks...


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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611923477_965610706-- From nobody Fri Jun 15 07:10: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 D7B2D130E0D for ; Fri, 15 Jun 2018 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Aiyna22N778 for ; Fri, 15 Jun 2018 07:10:37 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B64130DEF for ; Fri, 15 Jun 2018 07:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529071835; x=1529676635; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=kYb+Uu95l4d53JakHV5+Eh5q7uoMyl53KH 2mt7sjEvE=; b=iZ0LD4/Nyg+mgop6lGwzFtmqoevSyp6EiwNmJL4D5dHKUHMiHQ OMxDJR94n7PNXfP9QAyNw53xTdN7qscd5yG7xbv6n8APDk1S3DhmriQ2Q4/9IwZg QsGcGNk+pVBOfX+dqlEio4mG/a83gZgU6LTixOVi5FUNfF9CxbDg6yfek= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 15 Jun 2018 16:10:35 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 15 Jun 2018 16:10:34 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005790089.msg for ; Fri, 15 Jun 2018 16:10:32 +0200 X-MDRemoteIP: 2001:470:1f09:495:bc41:eb97:da67:6671 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Fri, 15 Jun 2018 16:10:32 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1704c2357c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 15 Jun 2018 16:10:27 +0200 From: JORDI PALET MARTINEZ To: Lee Howard , Message-ID: <6A9AC528-9EE8-4EDD-A568-D12CB52A47F6@consulintel.es> Thread-Topic: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas References: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> In-Reply-To: <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611923827_1509450345" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 14:10:40 -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_3611923827_1509450345 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable In short =E2=80=A6 mobile is so huge that impacts in everything, especially= in app developers. So, if they are forced by mobile to solve any problems,= it means they typically will be sorted out as well for wireline (if using = the same mechanisms). Is not that influence? =20 I think they opted for 464XLAT because it is a very simple approach half wa= y to the end of the path: IPv6-only. Cameron can confirm, but clearly, NAT6= 4 alone was not sufficient as it was breaking many things. =20 And that responds also your point about tethering, just agree on that, but = iOS not including it. I think there were other related inputs on this yeste= rday in the list. Regards, Jordi =20 =20 =20 De: Lee Howard Fecha: jueves, 14 de junio de 2018, 19:34 Para: JORDI PALET MARTINEZ , Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas =20 =20 =20 On 06/14/2018 10:20 AM, JORDI PALET MARTINEZ wrote: =20 I recall Windows Update 10 also has included CLAT support. I=E2=80=99m sure= this will happen more and more in different OSs, as it makes a lot of sens= e in networks that may already have NAT64. You think? Like game console OSs and thermostat OSs and stereo OSs and TV O= Ss?=20 No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It= makes a lot of sense specially for devices that are =E2=80=9Cportable=E2= =80=9D and in fact that=E2=80=99s the idea behind Windows 10 Update. If you= can use that device in a cellular IPv6-only network, should be expected th= at in a WiFi or wired IPv6-only network is behaving the same way when no na= tive IPv4 is available. The other kind of OSs that you mention should eithe= r have already IPv6-only or rely in the CPE to provide IPv4 if they really = need that. "Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so th= ey need whatever the home gateway provides. No transition mechanisms are wi= despread in retail gateways; DS-Lite more than others. So we're waiting to = see what goes into retail gateways. Meanwhile, manufacturers are asking ISP customers what they want. You keep = hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP. BUT it would be cool if game consoles did deploy CLAT, and provide a transl= ation layer for games that only know IPv4. I don't know the architecture we= ll enough to know whether that would work, Also, tethering behind an IPv6-only phone is still no problem if you have W= indows 10 and a NAT64 server, apparently: just fire up the CLAT. That only matters if it actually gets implemented. "Easy" and "done" are di= fferent. You've said that home gateway vendors by and large have code for all of the= mechanisms already written, so I'm not sure ease is essential. Yeah, talked to many, they often provide whatever you need if the order is = big, our problem is still the retail market or orders to vendors that don= =E2=80=99t have sufficient amount to demand a specific firmware feature set= . =20 Code required for each transition in OpenWRT (it may be quite similar in ot= her implementations): =20 DS-Lite 15 Kbytes 464XLAT 17 Kbytes MAP-E 35 Kbytes LW4o6 35 Kbytes MAP-T 48 Kbytes =20 If *all* them are implemented: 53 Kbytes (there are many =E2=80=9Cshared=E2= =80=9D modules among them, same data plane, etc.). There are other drivers here, and while I have no concerns about 464xlat, I= also am not ready to crown it the winner.=20 =20 I bet a dinner =E2=80=A6 Cellular is too powerful and they made the decisio= n long time ago. What's the decision criterion? :) Mobile is huge, but has little influence on wireline. And most of them (glo= bally) are still on dual stack. Lee Lee =20 Regarsd, Jordi =20 =20 =20 De: v6ops en nombre de Lee Howard Fecha: jueves, 14 de junio de 2018, 15:16 Para: Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really= inferior to all other IPv6 transition technologies? -- Re: updating RFC802= 6 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas =20 =20 =20 On 06/14/2018 08:12 AM, Ca By wrote: =20 =20 On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti wrote: On Thu, Jun 14, 2018 at 7:28 PM wrote: =20 =20 Oh, I definitely agree that 464xlat has it's place. I maintain a popular im= plementation of it :-) =20 I'm just saying it's not the best solution for a wireline network.=20 =20 Perhaps.=20 =20 The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.= =20 =20 Afaik, there is not a large production stateless MAP implementation, and th= is market is fairly mature. That said, at this point, the theoretical advan= tage of stateless has failed to materialize in real world deployment ... wh= ile the stateful solutions keep gaining share.=20 =20 Crowd-sourced list of transition technologies various carriers have deploye= d: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO= _7NK9vcVApc/edit#gid=3D0 I see several that have deployed MAP.=20 I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early d= evelopment), and were the only game in town. 464xlat only has that advantag= e in mobile, since handsets are the only major CLAT implementation.=20 I think it's too soon to declare winners. Lee _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3611923827_1509450345 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

In short =E2=80=A6 mobile is so huge that impacts in everythi= ng, especially in app developers. So, if they are forced by mobile to solve= any problems, it means they typically will be sorted out as well for wirel= ine (if using the same mechanisms). Is not that influence?

 

I think they opted for 464XLAT because= it is a very simple approach half way to the end of the path: IPv6-only. C= ameron can confirm, but clearly, NAT64 alone was not sufficient as it was b= reaking many things.

 

<= p class=3DMsoNormal>And that responds also your point about tethering, just agree on that, but= iOS not including it. I think there were other related inputs on this yest= erday in the list.


Regards,

=

Jordi<= /o:p>

 

 

=  

De: = Lee Howard <lee@asgard.org&= gt;
Fecha: jueves, 14 de junio de 2018, 19:34
Para: JOR= DI PALET MARTINEZ <jordi.palet@consulintel.es>, <v6ops@ietf.org>= ;
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 46= 4XLAT really inferior to all other IPv6 transition technologies? -- Re: upd= ating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

 <= /o:p>

 

On 06/14/2018 1= 0:20 AM, JORDI PALET MARTINEZ wrote:

 

I recall Windows Updat= e 10 also has included CLAT support. I=E2=80=99m sure this will happen more= and more in different OSs, as it makes a lot of sense in networks that may= already have NAT64.


You think? Like game c= onsole OSs and thermostat OSs and stereo OSs and TV OSs?



No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS= , Android). It makes a lot of sense specially for devices that are =E2=80= =9Cportable=E2=80=9D and in fact that=E2=80=99s the idea behind Windows 10 = Update. If you can use that device in a cellular IPv6-only network, should = be expected that in a WiFi or wired IPv6-only network is behaving the same = way when no native IPv4 is available. The other kind of OSs that you mentio= n should either have already IPv6-only or rely in the CPE to provide IPv4 if they really need that.


"Or rely on the CPE"= is my point. They don't have IPv6 in the OS now, so they need whatever the= home gateway provides. No transition mechanisms are widespread in retail g= ateways; DS-Lite more than others. So we're waiting to see what goes into r= etail gateways.
Meanwhile, manufacturers are asking ISP customers what t= hey want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep h= earing MAP.

BUT it would be cool if game consoles did deploy CLAT, a= nd provide a translation layer for games that only know IPv4. I don't know = the architecture well enough to know whether that would work,

Also, = tethering behind an IPv6-only phone is still no problem if you have Windows= 10 and a NAT64 server, apparently: just fire up the CLAT.


That only matters if it actually gets i= mplemented. "Easy" and "done" are different.

You= 've said that home gateway vendors by and large have code for all of the me= chanisms already written, so I'm not sure ease is essential.


Yeah, talked to many, they often provide whatever you need if the ord= er is big, our problem is still the retail market or orders to vendors that= don=E2=80=99t have sufficient amount to demand a specific firmware feature= set.

 

Code required for each transitio= n in OpenWRT (it may be quite similar in other implementations):

 

DS-Lite  = ; 15 Kbytes

464XLAT 17 Kbytes

MAP-E    35 Kbytes

LW4o6   = 35 Kbytes

M= AP-T   48 Kbytes

 

If *all* them are implemented: 53 Kbytes (th= ere are many =E2=80=9Cshared=E2=80=9D modules among them, same data plane, = etc.).


There are other drivers here, and while I have no= concerns about 464xlat, I also am not ready to crown it the winner.

 

I bet a dinner =E2=80=A6 Cellular is too po= werful and they made the decision long time ago.


What's the de= cision criterion? :)
Mobile is huge, but has little influence on wirelin= e. And most of them (globally) are still on dual stack.

Lee

<= o:p>



= Lee
 



Re= garsd,

= Jordi

 

=

 

 

De: v6ops <v6ops-bounces@ietf.org> en no= mbre de Lee Howard <lee@asgard.org>=
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really infer= ior to all other IPv6 transition technologies? -- Re: updating RFC8026 to s= upport 464XLAT in draft-ietf-v6ops-transition-ipv4aas

=

 

 

 

On 06/14/2018 08:12 AM, Ca By= wrote:

 <= o:p>



Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnj= LSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=3D0

I see several that hav= e deployed MAP.

I speculate that DS-Lite and NAT64 had early mover = advantage (i.e., early development), and were the only game in town. 464xla= t only has that advantage in mobile, since handsets are the only major CLAT= implementation.

I think it's too soon to declare winners.

L= ee



_______________________________________________ v6ops mai= ling list v6ops@ietf.org https://www.ietf.org/mailman/li= stinfo/v6ops


***= *******************************************
IPv4 is over
Are you read= y for the new Internet ?
http://ww= w.consulintel.es
The IPv6 Company

This electronic message con= tains information which may be privileged or confidential. The information = is intended to be for the exclusive use of the individual(s) named above an= d further non-explicilty authorized disclosure, copying, distribution or us= e of the contents of this information, even if partially, including attache= d files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, copying= , distribution or use of the contents of this information, even if partiall= y, including attached files, is strictly prohibited, will be considered a c= riminal offense, so you must reply to the original sender to inform about t= his communication and delete it.





**********************************************IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company
<= br>This electronic message contains information which may be privileged or = confidential. The information is intended to be for the exclusive use of th= e individual(s) named above and further non-explicilty authorized disclosur= e, copying, distribution or use of the contents of this information, even i= f partially, including attached files, is strictly prohibited and will be c= onsidered a criminal offense. If you are not the intended recipient be awar= e that any disclosure, copying, distribution or use of the contents of this= information, even if partially, including attached files, is strictly proh= ibited, will be considered a criminal offense, so you must reply to the ori= ginal sender to inform about this communication and delete it.




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3611923827_1509450345-- From nobody Fri Jun 15 08:22: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 60BE8130E2E for ; Fri, 15 Jun 2018 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYmfdUHiS3hm for ; Fri, 15 Jun 2018 08:22:32 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E5D130E2C for ; Fri, 15 Jun 2018 08:22:31 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id j15-v6so4583140wme.0 for ; Fri, 15 Jun 2018 08:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Vd7nkCKuhqP0EQRhfSI+sjp4pBHaadHOyMYMdDQ4M3U=; b=Qasm+R5dZfeYAZpaTVlwoc/JsMUwnO3wjOQh6ofxRPoA/OlzistfOG3sci5fDWYH9a uLorvgiI4RHCGJiLYLV7jVbDzIQtPi4tyRqET2Ps5YZVSq/QdxNKjBxecu1ycTcYOIRL U4p7xSWlFBc4Iyhm4qAyLlW7hKZU7B9jeYwKOn2KPC238DlzuzaBICi1kgKAeixyy2GV LBxhbAoNbm5zp7ofvQChndtSsQZq80PKyBKqupYRkGROQDQ95v0G2a5eWZ9X2X5Fems4 TRxc5j+NuYTG2ULdSEl8FOXA4LXbIUfpKAnuB2VoPLYNTBlbERfWfnD2vXDDTtLQtx8X ahKQ== 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=Vd7nkCKuhqP0EQRhfSI+sjp4pBHaadHOyMYMdDQ4M3U=; b=TMZYUbYS9Zy3XljmK3f1dLX5KEbT9LY9mBYXFXxQVl2Y3NgQ4j+bByG9ELs8QZLD+x OFO67mS5pqhU/Qqvyz6NEvac6lZPvCoLKk/OblmNTBhFxY0+bqYnocAiR+kmftrbLQoa gHMsx3EuaAnprcoypJhW0pWCwt+Ey9wSKBHM7Ry9r2obSjSJMEJMRIen3NbieBzGmsbf c9RxqNmOSTsiByW6I++XU3CMGlm2KH7mt5X6GmTEZ9tCv3v33QyVHI0EFXo5EpS58utI CPhHPnAo7mUaEkMDtpfR+8M/SdjUdOYi9LB0WljZEY8DNC5kt4SALk3oQy+MytS5Fp7a +Dzw== X-Gm-Message-State: APt69E0Xev+dm05Tl2F2p6gwTiQfRRs/yIcxU7PDRD43LaDtqR7IaXHa 6mKKsFl5RlT1Uf0xEJGTj3KFoydK X-Google-Smtp-Source: ADUXVKJu2WJ7H4hhtiUzfkmF/aFweXy+7dGZGCQWzKnvDcxlnkJ82WzRWoqQquS9Yzu59fTOw5pt8Q== X-Received: by 2002:a50:9b5b:: with SMTP id a27-v6mr2235057edj.60.1529076150289; Fri, 15 Jun 2018 08:22:30 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1006? ([2600:8802:5600:1546::1006]) by smtp.gmail.com with ESMTPSA id h2-v6sm3200824edq.6.2018.06.15.08.22.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 08:22:29 -0700 (PDT) From: Fred Baker Message-Id: <650E8347-D733-4F23-8E61-82DD84661117@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_02611575-3042-4602-875B-4B6167289E3C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 15 Jun 2018 08:22:25 -0700 In-Reply-To: <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> Cc: v6ops@ietf.org To: Alexandru Petrescu References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> <12796_1528998773_5B22AB74_12796_5985_1_E57F679B-6E08-4DFE-98A7-88D2962E3044@gmail.com> <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:22:34 -0000 --Apple-Mail=_02611575-3042-4602-875B-4B6167289E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 15, 2018, at 2:10 AM, Alexandru Petrescu = wrote: >=20 >> Yes, I'd like PayPal, Github, and a variety of >> other web sites to implement IPv6. I'm pretty sure their maintainers >> are not reading this list. >=20 > Well, I can pick one. The github. What is the postmaster address at = github? I can write her an email. That would be a constructive course of action. On this list, I'm afraid = the discussion is off topic. --Apple-Mail=_02611575-3042-4602-875B-4B6167289E3C 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+AFAlsj2bIACgkQEhdRnd2G P+BJJA/9HSo3bKDD0xMYTlMikFjDkFgVQ+SMhFIYoiMNHYrHnS+EMIOqS/zYVXtW t8YCUtM0o7KtdFXnk9X5iyIStfW+9B9M7xulXqbx8NjRG54HBaLH/BTinZkfGah3 +hfYNzS7AJyb6LtntaRijSsNGtba7B4kgY1O2hKy1jQb1/PyD3g+lqq6fWjORx9M KyS4Au+zL7T3gCuH7mSksyqvf6bYS/nD2Io4FxMoYgxW34xsYIDESOHd+RHvHCY0 R6GXDIcYPRylvY9Y/e4m1EtMBtSpNacBmPYQjXV469UYJqlw0c9qgJiyAYLesp8d VllCF6wx0shvIwcksHtpQd152F5Rtf45Q+CVUNB23NIv5fNojjCRIT8BsgMc//11 4cwX7G+Ii+YcbQWL1DpAmhdPwIzMEtzAa92SfI6bdGuq81Y8O95CoDB18Y5V7AwC XM2MPzKhzVp+s0LocPPrelieIujSvjOQXjhKI71NdRzeAuVp1QNdXM+cIN3Y57pU cSbaWkLZps8AC/6NeFaT/3XM3/sS4YqnUYVtlYeoikf/OeLAuEauCou6UImxCyCp 0FrI0TJdS4wl2qU0mFBEQMSPeXvBjY0jt6140gLjgKzxlAePtAmgIIuuGRZxKFTI 5yTW8hmDc3VC8U67Key2PO1ZZSqiYqraeqIOu+AMfxXMF5kp8p4= =pZQN -----END PGP SIGNATURE----- --Apple-Mail=_02611575-3042-4602-875B-4B6167289E3C-- From nobody Fri Jun 15 09:29: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 02EA1130E37 for ; Fri, 15 Jun 2018 09:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLPlzYRibYXt for ; Fri, 15 Jun 2018 09:29:03 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDDB7130DC0 for ; Fri, 15 Jun 2018 09:29:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGT0Iq036591 for ; Fri, 15 Jun 2018 18:29:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D4F8204DEA for ; Fri, 15 Jun 2018 18:29:00 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 27E7A204DE9 for ; Fri, 15 Jun 2018 18:29:00 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w5FGSx1s010286 for ; Fri, 15 Jun 2018 18:29:00 +0200 To: v6ops@ietf.org References: <5e02c3d9-5382-205e-f552-496da5c529bc@gmail.com> <1d3f3c55-9a06-8354-b6cd-a25cc2771422@gmail.com> <86c1f229-a9fc-854a-8921-3ec929ea44ab@gmail.com> <12796_1528998773_5B22AB74_12796_5985_1_E57F679B-6E08-4DFE-98A7-88D2962E3044@gmail.com> <14009477-0016-10dd-432a-f0b46976d8d0@gmail.com> <1528_1529076187_5B23D9DA_1528_18814_1_650E8347-D733-4F23-8E61-82DD84661117@gmail.com> From: Alexandre Petrescu Message-ID: <0d3fa1f4-90c3-4fb2-f8ef-cb2083ca8b04@gmail.com> Date: Fri, 15 Jun 2018 18:28:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1528_1529076187_5B23D9DA_1528_18814_1_650E8347-D733-4F23-8E61-82DD84661117@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] When IPv6 breaks IPv4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:29:11 -0000 Le 15/06/2018 17:22, Fred Baker a crit: > [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT DANGEREUSES] > > Ce message contient des pieces jointes potentiellement dangereuses car susceptibles de contenir des virus. Pour lutter contre l'expansion de ce type d'attaque, les documents [null] ont ete retires du message original ci-dessous. Pour les documents Office, le CEA recommande l'usage exclusif des formats plus recents exempts de macros comme DOCX, XLSX, PPTX, merci de le signaler a votre expediteur. > > Pour de plus amples informations ou pour connaitre les mecanismes de mise en quarantaine, vous pouvez vous rapprocher de votre service informatique ou consulter le site USCIpedia - rubrique PureMessage. > > ----------------MESSAGE ORGINAL ci-dessous------------------ > > > >> On Jun 15, 2018, at 2:10 AM, Alexandru Petrescu wrote: >> >>> Yes, I'd like PayPal, Github, and a variety of >>> other web sites to implement IPv6. I'm pretty sure their maintainers >>> are not reading this list. >> >> Well, I can pick one. The github. What is the postmaster address at github? I can write her an email. > > That would be a constructive course of action. On this list, I'm afraid the discussion is off topic. Why I posted here? this kind of discussion was on-topic during the IETF meeting in Singapore on the '100attendees' email list. Absent that list, I supposed v6ops email list was appropriate. I supposed, maybe wrongly, that github not doing IPv6 would have been a reason of concern for Microsoft after having acquired github, Microsoft who _was_ on topic to talk on v6ops about IPv6 in the office. I will stop here. Alex > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jun 15 14:23: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 3742C130E6D for ; Fri, 15 Jun 2018 14:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cto8J59FXieE for ; Fri, 15 Jun 2018 14:23:48 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A28D130E64 for ; Fri, 15 Jun 2018 14:23:48 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id j135-v6so4641894itj.1 for ; Fri, 15 Jun 2018 14:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=62Lyya7DGxvPjb+zXIwPNIY1mtlYMDKaWuJrBrQkFyI=; b=XhWnFXlOJcm6D59hcRbobUedQPzq6OMXbUhoPEHM05OnrXgL64bx/PsSGoLSD9if+n pe1QcTgU654xoZ0+FSgh+jpAGOcIvymnXQJ5xM363B4JP1p35TYre+g+cVS0p8tJbYzL 4P0bIvHpoxVt5nzcNJ7bjyD9gEZ8Vtmj1DGlfuFpAWLVx0myQuCUdVhi6olAad0p1K9T eAs+5ldwwPqzkI0DrEDR6MzmYXWZoeVOcOvxefnDpp71YiVDqvEmanEhPPZVYMsxuJ8B RE4TptT4Hfd1BiNYPT0+hjy5AR/9ExQIp3idyczqfT4g4E/W7TAUcSnHt+vkT9HhYqhr r+iw== 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=62Lyya7DGxvPjb+zXIwPNIY1mtlYMDKaWuJrBrQkFyI=; b=HA+7uHya9Z9DsJYnuAWJJXs5eEnCu2YHkGER2aMnQ0w5cm1eyaErYqJhhhQPZzs0Ik ysf7LdP1Nu1fM+NXUQm99R8A5HIF2m6SZmirE4g6qhx4VB48+TvcwCp2TI2kN41mNpDQ u+Yw/bbkHaKhFPRZ3OM032nSEwRd8aqUNURB8OsZc/VMsHybVw3pd7sMUJrAV9fXRfH0 klCgzmyK8NGL1OTZNG78YLOP9FxlTrR7IIZkOf3R/6GQCO4xIKmb9BoTvezldvTA5wUD 3b+xygFTU+HEQj6In4c5jCtbkswn2AVcdkCAzyNuwj1a/u4P095WKdyKAZfU+e+XzIdx 0mSg== X-Gm-Message-State: APt69E1uyQLK9LyrSGF92O8QilN+YtktwEsHQke12ioh+nIdrwjlK2nw JEQPMrloce+Ut2PLeaP32689B0p80+Dy77XaOVE= X-Google-Smtp-Source: ADUXVKLWvNOhAwWziKEv/uy49KRvsaGuhECVKEonpEddCr3J8VSEsdJITlJZFK8LiAnr1ABd3DakZaV3E6PpJu69peA= X-Received: by 2002:a24:7809:: with SMTP id p9-v6mr2608770itc.20.1529097827481; Fri, 15 Jun 2018 14:23:47 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 2002:a4f:4f4f:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 14:23:46 -0700 (PDT) In-Reply-To: References: From: Erik Nygren Date: Fri, 15 Jun 2018 17:23:46 -0400 X-Google-Sender-Auth: 2qqWj82BZDATC23mYr4h-VfcWKQ Message-ID: To: "Templin (US), Fred L" Cc: v6ops list Content-Type: multipart/alternative; boundary="000000000000d581a8056eb4d4e4" Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 21:23:50 -0000 --000000000000d581a8056eb4d4e4 Content-Type: text/plain; charset="UTF-8" I think this is extremely useful work. Some additional thoughts: * Container systems (eg, Docker) are an important illustrative use-case here worth mentioning in addition to VMs. For example, see the Docker IPv6 implementation notes describe something very similar to what we are describing here: https://docs.docker.com/v17.09/engine/userguide/ networking/default_network/ipv6/ It assumes each Docker server has its own prefix (eg, at least /80 but many of the examples are /64) that it assigns to containers out of. They give two examples, one for ND proxying and one for next-hop routing. The lack of PD-host model support in cloud service providers such as AWS makes it much harder to deploy IPv6 and Docker on something like AWS without resorting to horrible NAT66 hacks. * Another good illustrative use-case example might be implementing a NAT64 or similar service. * Perhaps talk more (in the introduction, if not elsewhere?) about what addresses get used for the next-hop when F is talking to R, in-terms of when it is using a link-local vs global-unicast address on R. There are likely use-cases for both? * Section 8 could use some better examples as well as some clarifications for readability. For example, when saying "When a node receives a shared or individual prefix" it should say over what protocol or type of message. And for "The node further does not perform the IPv6 ND address resolution function over upstream interfaces" this should be clarified as for just being for addresses within the delegated prefix. It would also help to clarify which cases the delegated prefixes being discussed are for that node or for a node it wishes to talk to. (ie, clarify the behavior for a node that shares an upstream interface/link with one or more hosts that have delegated prefixes.) * For security considerations, some attacks may still be possible through on-net hosts. (eg, if the local network contains an open recursive DNS resolver it could be tricked into making lots of on-upstream ND requests for the prefix.) This may fall into existing ND considerations, but is a corner case where the prefix delegation may not help enough? * Static provisioning plus iBGP next-hop advertisements is another provisioning mechanism that I've seen used. (For example, to assign 256 /64 delegated prefixes out of a single statically assigned /56 to route to ND-managed global-unicast service addresses. This has worked well other than being a pain to convince networks that it is reasonable to support.) * Is it work mentioning use-cases for "shared delegated prefixes", or does that add confusion and should be a topic for a future draft? In particular where nodes share a delegated prefix and the first-hop router F load-balances between them, such as via ECMP. A use-case might be a NAT64 or lw4o6 decapsulation service where one prefix is effectively delegated to a set of hosts which each have intentionally duplicate addresses. The primary change ends up being with ND. Best, Erik On Tue, May 29, 2018 at 3:13 PM, Templin (US), Fred L < Fred.L.Templin@boeing.com> wrote: > See below for a draft update to "IPv6 Prefix Delegation Models > ('draft-templin-v6ops-pdhost'). > This version (-20) updates figure 1 and adds informative text on the > relation to multi-addressing > (RFC7934 and RFC8273). Please review and comment. > > Fred > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, May 29, 2018 12:02 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-v6ops-pdhost-20.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 Prefix Delegation Models > Author : Fred L. Templin > Filename : draft-templin-v6ops-pdhost-20.txt > Pages : 14 > Date : 2018-05-29 > > Abstract: > IPv6 prefixes are typically delegated to requesting routers which > assign them to their downstream-attached links and networks. The > requesting node can provision the prefix according to whether it acts > as a router on behalf of any downstream networks and/or as a host on > behalf of its local applications. In the latter case, the requesting > node can use portions of the delegated prefix for its own multi- > addressing purposes. This document therefore considers prefix > delegation models for both the classic routing and multi-addressing > use cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000d581a8056eb4d4e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is extremely useful work.=C2=A0 Some add= itional thoughts:

* Container systems (eg, Docker)= are an important illustrative use-case here worth mentioning in addition t= o VMs.
=C2=A0 For example, see the Docker IPv6 implementation not= es describe something very similar to
=C2=A0 what we are describi= ng here:
=C2=A0 It assumes each Docker serve= r has its own prefix (eg, at least /80 but many of the examples are /64)
=C2=A0 that it assigns to containers out of.=C2=A0 They give two ex= amples, one for ND proxying
=C2=A0 and one for next-hop routing.= =C2=A0 The lack of PD-host model support in cloud service providers
=C2=A0 such as AWS makes it much harder to deploy IPv6 and Docker on som= ething like AWS
=C2=A0 without resorting to horrible NAT66 hacks.=

* Another good illustrative use-case example = might be implementing a NAT64 or similar service.

= * Perhaps talk more (in the introduction, if not elsewhere?) about what add= resses get
=C2=A0 used for the next-hop when F is talking to= R, in-terms of when it is using a link-local
=C2=A0 vs global-un= icast address on R.=C2=A0 There are likely use-cases for both?

* Section 8 could use some better examples as well as some= clarifications for readability.
=C2=A0 For example, when saying = "When a node receives a shared or individual prefix"
= =C2=A0 it should say over what protocol or type of message.
=C2= =A0 And for "The node further does not perform the
=C2= =A0IPv6 ND address resolution function over upstream interfaces"
=
=C2=A0this should be clarified as for just being for addresses within = the delegated prefix.
=C2=A0It would also help to clarify whi= ch cases the delegated prefixes
=C2=A0being discussed are for tha= t node or for a node it wishes to talk to.
=C2=A0 (ie, clarif= y the behavior for a node that shares an upstream interface/link
= =C2=A0 with one or more hosts that have delegated prefixes.)
=
* For security considerations, some attacks may still be pos= sible through
=C2=A0 on-net hosts.=C2=A0 (eg, if the local networ= k contains an open recursive DNS resolver
=C2=A0 it could be tric= ked into making lots of on-upstream ND requests for the prefix.)
= =C2=A0 This may fall into existing ND considerations, but is a corner case = where
=C2=A0 the prefix delegation may not help enough?
=

* Static provisioning plus iBGP next-hop advertise= ments is another
=C2=A0 provisioning mechanism that I've= seen used.=C2=A0=C2=A0 (For example, to assign 256 /64 delegated prefixes<= br>
=C2=A0 out of a=20 single statically assigned /56 to route to ND-managed global-unicast servic= e addresses.
=C2=A0 This has worked well other than being a pain = to convince networks that it is reasonable to=20 support.)

* Is it work mentioning use-cases fo= r "shared delegated prefixes",
=C2=A0 or does that= add confusion and should be a topic for a future draft?
=C2=A0 I= n particular where nodes share a delegated prefix and the first-hop router = F
=C2=A0 load-balances between them, such as via ECMP.=C2=A0= A use-case might be a NAT64
=C2=A0 or lw4o6 decapsulation s= ervice where one prefix is effectively delegated to a set
= =C2=A0 of hosts which each have intentionally duplicate addresses.
=C2=A0 The primary change ends up being with ND.

=
Best, Erik



On Tue, May 29, 2018 at 3:1= 3 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
See below for a draft update to= "IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost')= .
This version (-20) updates figure 1 and adds informative text on the relati= on to multi-addressing
(RFC7934 and RFC8273). Please review and comment.

Fred

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, May 29, 2018 12:02 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-v6ops-pdhost-20.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Prefix Delegation Models
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Fred= L. Templin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tem= plin-v6ops-pdhost-20.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-05-29

Abstract:
=C2=A0 =C2=A0IPv6 prefixes are typically delegated to requesting routers wh= ich
=C2=A0 =C2=A0assign them to their downstream-attached links and networks.= =C2=A0 The
=C2=A0 =C2=A0requesting node can provision the prefix according to whether = it acts
=C2=A0 =C2=A0as a router on behalf of any downstream networks and/or as a h= ost on
=C2=A0 =C2=A0behalf of its local applications.=C2=A0 In the latter case, th= e requesting
=C2=A0 =C2=A0node can use portions of the delegated prefix for its own mult= i-
=C2=A0 =C2=A0addressing purposes.=C2=A0 This document therefore considers p= refix
=C2=A0 =C2=A0delegation models for both the classic routing and multi-addre= ssing
=C2=A0 =C2=A0use cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-templin-v6ops-pdhost/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-te= mplin-v6ops-pdhost-20
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-templin-v6ops-pdhost-20


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

--000000000000d581a8056eb4d4e4-- From nobody Fri Jun 15 23:41:43 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 C86E51277D2; Fri, 15 Jun 2018 23:41:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152913129475.6670.9390877007080250614@ietfa.amsl.com> Date: Fri, 15 Jun 2018 23:41:34 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 06:41:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-03.txt Pages : 20 Date : 2018-06-15 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 15 23:56: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 C43E1130FC4 for ; Fri, 15 Jun 2018 23:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQCChHFqaPMg for ; Fri, 15 Jun 2018 23:56:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3680A1277D2 for ; Fri, 15 Jun 2018 23:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529132201; x=1529737001; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=KutdPTl0 6h90Y2eiuf+zGBM+UNFXAdeWA7gV9Uzur3Q=; b=HAg9PtHVV3YzBcJqEleFeV6y ALpsdnrNVIdO8VdtRPVYzXKiZ0dlcT2kZQSUviR9kqD/mZHwbC7aYGWkrZIGokdB pnhVGHvs3UECEYwTmifpyb8U5dVrD06cWTFVlyeHRLuTUDjkkuj1W0BWn3EO1IWF sHPr4Z/ygYFXt9jtaEM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 16 Jun 2018 08:56:41 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 16 Jun 2018 08:56:41 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005790458.msg for ; Sat, 16 Jun 2018 08:56:40 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8ed:d1d7:bcd5:e75d X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sat, 16 Jun 2018 08:56:40 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17050482c2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Sat, 16 Jun 2018 08:56:38 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> In-Reply-To: <152913129475.6670.9390877007080250614@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 06:56:47 -0000 Hi all, As indicated a couple of day ago, we have updated this document, so instead= of an update of RFC8026 and a new option code, we only need to ask IANA to= use a NAT64 existing one for the RFC8026 priority table. https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Let's know any comments you have. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: s=C3=A1bado, 16 de junio de 2018, 8:43 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-03.txt Pages : 20 Date : 2018-06-15 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-03 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -03 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 18 01:30:51 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 5DEFC130DE6; Mon, 18 Jun 2018 01:30:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152931064435.3012.11310551618714702332@ietfa.amsl.com> Date: Mon, 18 Jun 2018 01:30:44 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 08:30:45 -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 : Using Conditional Router Advertisements for Enterprise Multihoming Authors : Jen Linkova Massimiliano Stucchi Filename : draft-ietf-v6ops-conditional-ras-05.txt Pages : 18 Date : 2018-06-18 Abstract: This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The "ietf-rtgwg- enterprise-pa-multihoming" document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue and using Router Advertisements to influence the host source address selection. While the above-mentioned document focuses on solving the general problem and on covering various complex use cases, this document adopts the approach proposed in the "ietf-rtgwg-enterprise-pa- multihoming" draft to provide a solution for a limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/ backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC8028. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-05 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 18 01:38: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 2BDAE130DC5; Mon, 18 Jun 2018 01:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8gIF55O3lVW; Mon, 18 Jun 2018 01:38:07 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 3CF071277D2; Mon, 18 Jun 2018 01:38:07 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id y20-v6so23364355lfy.0; Mon, 18 Jun 2018 01:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iSPXT4k4DX6a8eyH1H8KONIrFp041Qqj1XG1avi0BPo=; b=mnJv0Kk0F5nxJksgqNYSmJxOFH8IBAVSHpS/Pgve8c0x2Iv5mFGnF9WrsmlhdQXJv0 PpgHh2ig7VCBcL0/xJr4NjgxSS5dUJnVWwA1PnG/LRyHtwpbsJZQIAduoPHkReZ+jffK 4egqe5+plPBRAXDXk4ak3zNCn6QEW49o2rQk9r1qs6Z5KuNGvo0w7Wjpg7ViLofqMaF1 l9T/X9YyTWoeCgn+MmoxO5aMYu9DXlCW2QSwM8VTc2U82C17RaEwhuIst+3fMUlGSboe 8pqVUNcHyJYzKu096xdIfcFLgLrZqB96bVY3WE+7x/YoZ+H3k9fxRSv03lFR8DrCOcGr vNMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=iSPXT4k4DX6a8eyH1H8KONIrFp041Qqj1XG1avi0BPo=; b=uMd/KH+l+hkjwPlWyPq4vEV1/zWq6/8k84c7coX3cvYRXBlyWv47CigPQ4s7m5AYrw UVmoIyt0bcgnV6bFNHXMvoqJeTAQ8iVlX2vNE82aIHw95svg9om9KBgaxYSON1k9U5CL nFgrX40Oo4xEOd3239llEyTHJcqo8CX4+kmYW8WggWG4DZAK1I4f8n92d6D2eEoTd7Pg b0g3fh1bFIKWHGpGFlDNkF7Il9nGbw3WkddPXx5FmuQeM2xIk+vipfTv1QYAJivrkn9y WWJ911VPWS3T9cVFSjsV+p7OWbzxNmeBTMvDM8Ohafzy7cvc5r3wiYgsOfAqBTZCfyvd AS9g== X-Gm-Message-State: APt69E1GmPBve46RiLKd3D8aT+F3Qv1HY/tvzVMXMlq5d40PDiKeEvEd 2aRSDdHUUtORPo+dQb/URVOcDCP1VWU5Ad7yz3EB43JV X-Google-Smtp-Source: ADUXVKL8cUI2RmF0iLc2nMq+t6u/F9CnWsGpQtT4zwxOhMSBkoFlDEo2tXIf2JFaGH+4LMR3m0nNg3WK2sIUgs9KwNQ= X-Received: by 2002:a19:e21b:: with SMTP id z27-v6mr1363672lfg.119.1529311085310; Mon, 18 Jun 2018 01:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1dd0:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 01:37:44 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Mon, 18 Jun 2018 18:37:44 +1000 Message-ID: To: Ravi Singh Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-conditional-ras@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 08:38:10 -0000 Hi Ravi, My apologies for the delay with addressing issues you raised in your review= ! I've just uploaded -05 version, https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ please let me know if it still has any issues. On Tue, May 22, 2018 at 9:25 AM, Ravi Singh wrote: > Document: draft-ietf-v6ops-conditional-ras > Summary: This document is basically ready for publication, but has nits t= hat should be considered prior to publication. > > Nits: > d. Section 3.2.3: typo: quoted section # needs correction. > " correct uplink based on the source address as described in Se= ction 3.2.1." > -> > "correct uplink based on the source address as described in Sect= ion 3.1.1." The reference was actually correct, I've updated the wording to make it more clear. > 4. Section 3.3 & 3.4: the text seems to indicate that this draft if propo= sing some solution, even though as indicated in this draft's abstract=E2=80= =A6.the solution being referenced is in ietf-rtgwg-enterprise-pa-multihomin= g and this draft if describing the use of that solution in sample scenarios= . Slight rewording of text should help to address this. I've updated the abstract and the Introduction section to clarify that this draft provides a solution based on the general approach discussed in ietf-rtgwg-enterprise-pa-multihoming. --=20 SY, Jen Linkova aka Furry From nobody Mon Jun 18 01:48:01 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 C97171277D2; Mon, 18 Jun 2018 01:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANI9o8RRd9Ma; Mon, 18 Jun 2018 01:47:46 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771D61277C8; Mon, 18 Jun 2018 01:47:46 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a13-v6so3277375lfk.12; Mon, 18 Jun 2018 01:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7HMSW4SYfoHcionizx72xH1p+jPxKvUgxsZGN1t9Apc=; b=mgnQazl0NCQbsCh6iPvYHe1FUJBC4TcP0dtWcPjAT0kRLX+AoMnnWB3q9t/6tPKnj6 J3KEJXru2nbrhMvWgOxn92cATSmcyaoiBKwj7JdCyM3t5rdvhmbuPbnc4k0WPHg0ev0c yZfy1hacW+rgv69WoYbjk0IbgYXtHvcA54agnkhu981Z3JTU5MEhpRjaov06radIgpJj V1t14r9KcEMOCrMnUkWO3j/F7fjkmR1y1uFGHeKf7eueRwV4ZLl6GZkQwvS0BVxCMrUL hS3t0Io0VjgNWKV0CHgQExvEoIacz4/kg8IKgl8GOIBKDP0PBM+I/jtuqy71o36WQ6Of yrSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/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=7HMSW4SYfoHcionizx72xH1p+jPxKvUgxsZGN1t9Apc=; b=snbdfuk8UFCL+s0sH5DcE9v5kAB72629ft3iyzif85a+5huvwnVETIBDjQDxjw+YZE GyWXb67kTyDP8chpmiJCWFBeQusfNvxAHkskWudgA/TBxxirjBGdNVINSUyAQJyWtgP7 YNu+fOpe9wO3IKM6M4kUAq8RijEvvrfbwBfpdhT63u90zeWAp1FjYTrl3T8BLH+ZRYMr kJZyV7MBD2xLWQ++5Elze4VqQwPucZwwqRJnpyjFz60vymjH1uLJvzZTnOmXzeI9CUH+ 4f3CF4MzWGMGKNTk+qCtiLBn1bFL0jMmy2P7CvqEzhOp893W1I0e4D2oNbdq7tdWdwku hZyw== X-Gm-Message-State: APt69E065iL3uPrqlYw+GUinpWVdOW8LVUQE4X/OBlSbrhKwXKA0rIxP fkdIOuCc9Nq0sJDSh1jqr7uMN+po5nIRDjHbjOYNjIOm X-Google-Smtp-Source: ADUXVKIa2BRy+unoZFi/g7kYT+mbtJhhj9EAdztb5ZRmjmuXSxjjOuigE0naEe+goJVirI82eefpGA6zBxinTc2O7+A= X-Received: by 2002:a2e:28b:: with SMTP id y11-v6mr7319087lje.27.1529311664538; Mon, 18 Jun 2018 01:47:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1dd0:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 01:47:23 -0700 (PDT) In-Reply-To: <152689102802.23045.6041887435563645658@ietfa.amsl.com> References: <152689102802.23045.6041887435563645658@ietfa.amsl.com> From: Jen Linkova Date: Mon, 18 Jun 2018 18:47:23 +1000 Message-ID: To: Sheng Jiang Cc: ops-dir@ietf.org, draft-ietf-v6ops-conditional-ras.all@ietf.org, V6 Ops List , IETF Rinse Repeat Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Opsdir last call review of draft-ietf-v6ops-conditional-ras-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 08:47:48 -0000 Hi Sheng, On Mon, May 21, 2018 at 6:23 PM, Sheng Jiang wrote: > Review result: Has Issues > Minor issue: There are many unused reference. However, they are not simple Nits > and cannot be fixed by deleting them from reference list. Many of these unused > reference are really relevant and should have some content to describe the > relationship with the mechanism or scenario of the document, such as RFC6296 > NAT66, etc. I've checked all unused references and added most of them to the draft text. However some of them had to be removed as they are more relevant to the general multihoming discussion and other potential solutions to that problem, which are discussed in the https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming (see Section 7 of that doc). Using SLAAC vs NAT etc is discussed in details there. As draft-ietf-v6ops-conditional-ras is more about applying the approach defined in draft-ietf-rtgwg-enterprise-pa-multihoming to the particular subset of use cases, it seems unnecessary to have the same text in both documents, especially as draft-ietf-v6ops-conditional-ras explicitly refers to draft-ietf-rtgwg-enterprise-pa-multihoming for details explanation why the particular mechanism is proposed. Please let me know if the updated version does not address your concerns! Thank you! -- SY, Jen Linkova aka Furry From nobody Mon Jun 18 03:57: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 EEB89130EB7; Mon, 18 Jun 2018 03:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtyizIu9MGNz; Mon, 18 Jun 2018 03:57:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E01130EA5; Mon, 18 Jun 2018 03:57:08 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 862F9AA275CC0; Mon, 18 Jun 2018 11:57:04 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 18 Jun 2018 11:57:06 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Mon, 18 Jun 2018 18:57:02 +0800 From: Sheng Jiang To: Jen Linkova CC: "ops-dir@ietf.org" , "draft-ietf-v6ops-conditional-ras.all@ietf.org" , V6 Ops List , IETF Rinse Repeat Thread-Topic: Opsdir last call review of draft-ietf-v6ops-conditional-ras-04 Thread-Index: AQHUBuEKU6siIzMgYUKz9dlT4mI2ZaRl02Tg Date: Mon, 18 Jun 2018 10:57:01 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92900E6CF1@NKGEML515-MBX.china.huawei.com> References: <152689102802.23045.6041887435563645658@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.187.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Opsdir last call review of draft-ietf-v6ops-conditional-ras-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 10:57:13 -0000 SGksIEplbiwNCg0KMDUgdmVyc2lvbiBsb29rcyBmaW5lIGZvciBtZS4gWW91ciBleHBsYW5hdGlv biBhcmUgcmVhc29uYWJsZS4gVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IGNvbW1lbnRzLg0KDQpS ZWdhcmRzLA0KDQpTaGVuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmVu IExpbmtvdmEgW21haWx0bzpmdXJyeTEzQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEp1bmUg MTgsIDIwMTggNDo0NyBQTQ0KVG86IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+ DQpDYzogb3BzLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi12Nm9wcy1jb25kaXRpb25hbC1yYXMu YWxsQGlldGYub3JnOyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBJRVRGIFJpbnNlIFJl cGVhdCA8aWV0ZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBPcHNkaXIgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLXY2b3BzLWNvbmRpdGlvbmFsLXJhcy0wNA0KDQpIaSBTaGVuZywNCg0K T24gTW9uLCBNYXkgMjEsIDIwMTggYXQgNjoyMyBQTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdA aHVhd2VpLmNvbT4gd3JvdGU6DQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gTWlub3Ig aXNzdWU6IFRoZXJlIGFyZSBtYW55IHVudXNlZCByZWZlcmVuY2UuIEhvd2V2ZXIsIHRoZXkgYXJl IG5vdCANCj4gc2ltcGxlIE5pdHMgYW5kIGNhbm5vdCBiZSBmaXhlZCBieSBkZWxldGluZyB0aGVt IGZyb20gcmVmZXJlbmNlIGxpc3QuIA0KPiBNYW55IG9mIHRoZXNlIHVudXNlZCByZWZlcmVuY2Ug YXJlIHJlYWxseSByZWxldmFudCBhbmQgc2hvdWxkIGhhdmUgDQo+IHNvbWUgY29udGVudCB0byBk ZXNjcmliZSB0aGUgcmVsYXRpb25zaGlwIHdpdGggdGhlIG1lY2hhbmlzbSBvciANCj4gc2NlbmFy aW8gb2YgdGhlIGRvY3VtZW50LCBzdWNoIGFzIFJGQzYyOTYgTkFUNjYsIGV0Yy4NCg0KSSd2ZSBj aGVja2VkIGFsbCB1bnVzZWQgcmVmZXJlbmNlcyBhbmQgYWRkZWQgbW9zdCBvZiB0aGVtIHRvIHRo ZSBkcmFmdCB0ZXh0LiBIb3dldmVyIHNvbWUgb2YgdGhlbSBoYWQgdG8gYmUgcmVtb3ZlZCBhcyB0 aGV5IGFyZSBtb3JlIHJlbGV2YW50IHRvIHRoZSBnZW5lcmFsIG11bHRpaG9taW5nIGRpc2N1c3Np b24gYW5kIG90aGVyIHBvdGVudGlhbCBzb2x1dGlvbnMgdG8gdGhhdCBwcm9ibGVtLCB3aGljaCBh cmUgZGlzY3Vzc2VkIGluIHRoZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGd3Zy1lbnRlcnByaXNlLXBhLW11bHRpaG9taW5nDQooc2VlIFNlY3Rpb24gNyBvZiB0aGF0 IGRvYykuIFVzaW5nIFNMQUFDIHZzIE5BVCBldGMgaXMgZGlzY3Vzc2VkIGluIGRldGFpbHMgdGhl cmUuDQoNCkFzIGRyYWZ0LWlldGYtdjZvcHMtY29uZGl0aW9uYWwtcmFzIGlzIG1vcmUgYWJvdXQg YXBwbHlpbmcgdGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1ydGd3Zy1lbnRlcnBy aXNlLXBhLW11bHRpaG9taW5nIHRvIHRoZSBwYXJ0aWN1bGFyIHN1YnNldCBvZiB1c2UgY2FzZXMs IGl0IHNlZW1zIHVubmVjZXNzYXJ5IHRvIGhhdmUgdGhlIHNhbWUgdGV4dCBpbiBib3RoIGRvY3Vt ZW50cywgZXNwZWNpYWxseSBhcyBkcmFmdC1pZXRmLXY2b3BzLWNvbmRpdGlvbmFsLXJhcyBleHBs aWNpdGx5IHJlZmVycyB0byBkcmFmdC1pZXRmLXJ0Z3dnLWVudGVycHJpc2UtcGEtbXVsdGlob21p bmcgZm9yIGRldGFpbHMgZXhwbGFuYXRpb24gd2h5IHRoZSBwYXJ0aWN1bGFyIG1lY2hhbmlzbSBp cyBwcm9wb3NlZC4NCg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZSB1cGRhdGVkIHZlcnNpb24g ZG9lcyBub3QgYWRkcmVzcyB5b3VyIGNvbmNlcm5zIQ0KDQpUaGFuayB5b3UhDQoNCi0tDQpTWSwg SmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Mon Jun 18 05:26: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 7F134130EC5 for ; Mon, 18 Jun 2018 05:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.795, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DGvjefOfCos for ; Mon, 18 Jun 2018 05:26:28 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E70130EC2 for ; Mon, 18 Jun 2018 05:26:28 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 8D77BC068D; Mon, 18 Jun 2018 14:26:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 69DE71C005D; Mon, 18 Jun 2018 14:26:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0399.000; Mon, 18 Jun 2018 14:26:26 +0200 From: To: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Thread-Index: AQHUBT0nGnkbjcz0mUSDSM4Y2dmnwaRiUlYAgAOh7iA= Date: Mon, 18 Jun 2018 12:26:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 12:26:32 -0000 SGkgSm9yZGksIA0KDQpGV0lXLCBwbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIHRvIHRoaXMgZHJh ZnQgYXQ6IA0KDQpwZGY6IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMt UmV2aWV3cy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0w My1yZXYlMjBNZWQucGRmIA0KZG9jOiBodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL0lFVEYt RHJhZnRzLVJldmlld3MvcmF3L21hc3Rlci9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2 NGFhcy0wMy1yZXYlMjBNZWQuZG9jIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQo+IEVudm95w6nCoDogc2Ft ZWRpIDE2IGp1aW4gMjAxOCAwODo1Nw0KPiDDgMKgOiB2Nm9wc0BpZXRmLm9yZw0KPiBPYmpldMKg OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2 NGFhcy0wMy50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IA0KPiANCj4gQXMgaW5kaWNhdGVkIGEg Y291cGxlIG9mIGRheSBhZ28sIHdlIGhhdmUgdXBkYXRlZCB0aGlzIGRvY3VtZW50LCBzbyBpbnN0 ZWFkDQo+IG9mIGFuIHVwZGF0ZSBvZiBSRkM4MDI2IGFuZCBhIG5ldyBvcHRpb24gY29kZSwgd2Ug b25seSBuZWVkIHRvIGFzayBJQU5BIHRvDQo+IHVzZSBhIE5BVDY0IGV4aXN0aW5nIG9uZSBmb3Ig dGhlIFJGQzgwMjYgcHJpb3JpdHkgdGFibGUuDQo+IA0KPiANCj4gDQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFh cy8/aW5jbHVkZV90ZXh0PTENCj4gDQo+IA0KPiANCj4gTGV0J3Mga25vdyBhbnkgY29tbWVudHMg eW91IGhhdmUuDQo+IA0KPiANCj4gDQo+IFRoYW5rcyENCj4gDQo+IA0KPiANCj4gUmVnYXJkcywN Cj4gDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDvu78tLS0tLU1lbnNh amUgb3JpZ2luYWwtLS0tLQ0KPiANCj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3Jn PiBlbiBub21icmUgZGUgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gDQo+IEZlY2hhOiBz w6FiYWRvLCAxNiBkZSBqdW5pbyBkZSAyMDE4LCA4OjQzDQo+IA0KPiBQYXJhOiA8aS1kLWFubm91 bmNlQGlldGYub3JnPg0KPiANCj4gQ0M6IDx2Nm9wc0BpZXRmLm9yZz4NCj4gDQo+IEFzdW50bzog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0w My50eHQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVz Lg0KPiANCj4gICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0 aW9ucyBXRyBvZiB0aGUgSUVURi4NCj4gDQo+IA0KPiANCj4gICAgICAgICAgICAgVGl0bGUgICAg ICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBJUHY2IEN1c3RvbWVyIEVkZ2UgUm91dGVycyB0bw0K PiBTdXBwb3J0IElQdjQgQ29ubmVjdGl2aXR5IGFzLWEtU2VydmljZQ0KPiANCj4gICAgICAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogSm9yZGkgUGFsZXQgTWFydGluZXoNCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEhhbnMgTS4tSC4gTGl1DQo+IA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXNhbm9idSBLYXdhc2hpbWENCj4gDQo+ICAgICAJRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDMudHh0DQo+IA0K PiAgICAgCVBhZ2VzICAgICAgICAgICA6IDIwDQo+IA0KPiAgICAgCURhdGUgICAgICAgICAgICA6 IDIwMTgtMDYtMTUNCj4gDQo+IA0KPiANCj4gICAgIEFic3RyYWN0Og0KPiANCj4gICAgICAgIFRo aXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSByZXF1aXJl bWVudHMgZm9yDQo+IA0KPiAgICAgICAgYW4gSVB2NiBDdXN0b21lciBFZGdlIChDRSkgcm91dGVy LCBlaXRoZXIgcHJvdmlkZWQgYnkgdGhlIHNlcnZpY2UNCj4gDQo+ICAgICAgICBwcm92aWRlciBv ciB0aHJ1IHRoZSByZXRhaWwgbWFya2V0Lg0KPiANCj4gDQo+IA0KPiAgICAgICAgU3BlY2lmaWNh bGx5LCB0aGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlICJCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQ djYNCj4gDQo+ICAgICAgICBDdXN0b21lciBFZGdlIFJvdXRlcnMiIGluIG9yZGVyIHRvIGFsbG93 IHRoZSBwcm92aXNpb25pbmcgb2YgSVB2Ng0KPiANCj4gICAgICAgIHRyYW5zaXRpb24gc2Vydmlj ZXMgZm9yIHRoZSBzdXBwb3J0IG9mICJJUHY0IGFzLWEtU2VydmljZSIgKElQdjRhYVMpDQo+IA0K PiAgICAgICAgYnkgbWVhbnMgb2YgbmV3IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gIFRoZSBkb2N1 bWVudCBvbmx5IGNvdmVycw0KPiANCj4gICAgICAgIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGZv ciBkZWxpdmVyaW5nIElQdjQgaW4gSVB2Ni1vbmx5IGFjY2Vzcw0KPiANCj4gICAgICAgIG5ldHdv cmtzLCBjb21tb25seSBjYWxsZWQgIklQdjQgYXMtYS1TZXJ2aWNlIiAoSVB2NGFhUyksIGFzIHJl cXVpcmVkDQo+IA0KPiAgICAgICAgaW4gYSB3b3JsZCB3aGVyZSBJUHY0IGFkZHJlc3NlcyBhcmUg bm8gbG9uZ2VyIGF2YWlsYWJsZSwgc28gaG9zdHMgaW4NCj4gDQo+ICAgICAgICB0aGUgY3VzdG9t ZXIgTEFOcyB3aXRoIElQdjQtb25seSBvciBJUHY2LW9ubHkgYXBwbGljYXRpb25zIG9yDQo+IA0K PiAgICAgICAgZGV2aWNlcywgcmVxdWlyaW5nIHRvIGNvbW11bmljYXRlIHdpdGggSVB2NC1vbmx5 IHNlcnZpY2VzIGF0IHRoZQ0KPiANCj4gICAgICAgIEludGVybmV0LCBhcmUgc3RpbGwgYWJsZSB0 byBkbyBzby4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgICAgVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IA0KPiAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMvDQo+ IA0KPiANCj4gDQo+ICAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQo+IA0KPiAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt djZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTAzDQo+IA0KPiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IGlwdjRh YXMtMDMNCj4gDQo+IA0KPiANCj4gICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCj4gDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDMNCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiANCj4gICAgIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+IA0KPiANCj4gDQo+ICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IA0KPiAgICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCj4gDQo+IA0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+IA0K PiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBpcyBvdmVyDQo+IEFy ZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8vd3d3LmNvbnN1bGlu dGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdl IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNvbmZp ZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVz aXZlIHVzZSBvZiB0aGUNCj4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBu b24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsDQo+IGNvcHlpbmcsIGRpc3RyaWJ1 dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYN Cj4gcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUNCj4gdGhhdCBhbnkgZGlz Y2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2Yg dGhpcw0KPiBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hl ZCBmaWxlcywgaXMgc3RyaWN0bHkNCj4gcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEg Y3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlDQo+IG9yaWdpbmFsIHNl bmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+ IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Mon Jun 18 07:38: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 C1CF4126F72 for ; Mon, 18 Jun 2018 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDQlXagfc2IQ for ; Mon, 18 Jun 2018 07:38:43 -0700 (PDT) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21338120049 for ; Mon, 18 Jun 2018 07:38:43 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5IEcdF8037751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 18 Jun 2018 10:38:39 -0400 Received: (qmail 23050 invoked by uid 0); 18 Jun 2018 14:38:39 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 18 Jun 2018 14:38:39 -0000 To: v6ops@ietf.org References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> From: Lee Howard Message-ID: <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> Date: Mon, 18 Jun 2018 10:38:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> Content-Type: multipart/alternative; boundary="------------E3A2CADEC8504E018703EC02" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:38:47 -0000 This is a multi-part message in MIME format. --------------E3A2CADEC8504E018703EC02 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Apparently I'm a week late on this thread. Sorry. I think an internet-draft in this case would be useful for reflecting the current best knowledge about the technologies. Even if it takes two years or more to publish, a draft is useful to collect  and summarize the detailed academic papers being published, and the structure of writing the draft will help point out areas where further research is needed. I'm also interested in supporting this work, up to and including working with your students,  providing my own test results, and/or co-authoring. Lee On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote: > > I’m not sure it makes sense something that is not published in, let’s > say, maximum one year from now. > > Anyway, I’m happy to help. > > By the way, I got some private questions about this … The table that > I’ve posted yesterday, was developed about 3 years ago, and I’ve not > updated it since them. Actually from emails exchanged today, I > discovered a couple of mistakes and also things that can be improved, > so if needed I can update it as well. > > > Regards, > > Jordi > > *De: *v6ops en nombre de Lencse Gábor > > *Fecha: *viernes, 15 de junio de 2018, 14:25 > *Para: *Fred Baker > *CC: * > *Asunto: *[v6ops] Pros and Cons of IPv6 Transition Technologies for > IPv4aaS -- Re: no need to update RFC8026 in > draft-ietf-v6ops-transition-ipv4aas > > Dear Fred, > > Thank you very much for your invitation. I am willing to accept it, > but I would like to clarify your expectations before saying 'yes'. > > I have several questions. > > 1. Depth of the analysis > > - Basic level: well-known advantages and disadvantages, similarly as > people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. > - Advanced level: basic level + security analysis using the > methodology defined in [1] + performance analysis according to RFC 8219. > > What depth do you recommend? > > 2. Method for getting the results and their publication > > As for the information for the basic level, I would prepare a google > docs table, fill in the information I have and send the link to the > v6ops list asking contributions. > After commenting and discussing, I would compile it to an I-D. > > Do you think that v6ops WG would finally agree to publish it as an RFC? > > As for the information for the advanced level, I would work together > with my students and PhD students, and publish our results first in > academic papers and then include their most important lessons into the > I-D. > > What do you think of it? > > 3. Timeline > > I think that I could put together the first table in a few weeks. The > contribution of the v6ops list members and the discussion could be > done in a few months and then I could compile the results into an I-D > in a few weeks. Perhaps, it could be presented at IETF 103. > > The further parts would require much more time and results could be > included gradually in 1-2 years. > > 4. Scope > > The smallest natural scope includes the technologies for IPv4AAS, that > is: 464XLAT, DS-Lite, MAP-T/E and lw4o6. > > IPv6 transition technologies for other carefully selected scenarios > might also be included. E.g. I have significant amount of results in > benchmarking DNS64 servers, having a testing tool [2], a well defined > methodology [3] and ready to use results concerning the DNS64 > performance of BIND, PowerDNS and Unbound [4]. > One of my PhD students is currently benchmarking some sateless NAT64 > implementations according the the dual DUT setup of RFC 8219 using an > RFC 2544 compatible Tester. Another PhD student is currently working > on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able > to perform single DUT setup NAT64 benchmarking tests. > > Thus, the scope can be widened, if you would like to. > > What do you think about my recommendations? > > Best regards, > > Gábor > > References: > > [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification > of potential security issues of different IPv6 transition > technologies: Threat analysis of DNS64 and stateful NAT64", /Computers > & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, > DOI: 10.1016/j.cose.2018.04.012 > > [2] G. Lencse, D. Bakai, "Design and implementation of a test program > for benchmarking DNS64 servers", /IEICE Transactions on > Communications/, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: > 10.1587/transcom.2016EBN0007 > > [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking > Methodology for DNS64 Servers", /Computer Communications/ (Elsevier), > vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: > 10.1016/j.comcom.2017.06.004 > > [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: > Theory and Practice", /Computer Communications/ (Elsevier), vol. 127, > no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 > > 6/14/2018 10:42 PM keltezéssel, Fred Baker írta: > > On Jun 14, 2018, at 1:15 PM, Lencse Gábor wrote: > > I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.) > > It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder. > > We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost. > > So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T. > > And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic). > > If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks... > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------E3A2CADEC8504E018703EC02 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Apparently I'm a week late on this thread. Sorry.

I think an internet-draft in this case would be useful for reflecting the current best knowledge about the technologies. Even if it takes two years or more to publish, a draft is useful to collect  and summarize the detailed academic papers being published, and the structure of writing the draft will help point out areas where further research is needed.

I'm also interested in supporting this work, up to and including working with your students,  providing my own test results, and/or co-authoring.

Lee


On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote:

I’m not sure it makes sense something that is not published in, let’s say, maximum one year from now.

 

Anyway, I’m happy to help.

 

By the way, I got some private questions about this … The table that I’ve posted yesterday, was developed about 3 years ago, and I’ve not updated it since them. Actually from emails exchanged today, I discovered a couple of mistakes and also things that can be improved, so if needed I can update it as well.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse Gábor <lencse@hit.bme.hu>
Fecha: viernes, 15 de junio de 2018, 14:25
Para: Fred Baker <fredbaker.ietf@gmail.com>
CC: <v6ops@ietf.org>
Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

 

Dear Fred,

Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'.

I have several questions.

1. Depth of the analysis

- Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219.

What depth do you recommend?

2. Method for getting the results and their publication

As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions.
After commenting and discussing, I would compile it to an I-D.

Do you think that v6ops WG would finally agree to publish it as an RFC?

As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D.

What do you think of it?

3. Timeline

I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103.

The further parts would require much more time and results could be included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.

IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4].
One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests.

Thus, the scope can be widened, if you would like to.

What do you think about my recommendations?

Best regards,

Gábor

References:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007

[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

6/14/2018 10:42 PM keltezéssel, Fred Baker írta:

 
On Jun 14, 2018, at 1:15 PM, Lencse Gábor <lencse@hit.bme.hu> wrote:
I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.)
It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder.
 
We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost.
 
So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T.
 
And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic).
 
If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks...


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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



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

--------------E3A2CADEC8504E018703EC02-- From nobody Mon Jun 18 10:05: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 0FFE8130DF9 for ; Mon, 18 Jun 2018 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0HiEQ-bm3VE for ; Mon, 18 Jun 2018 10:05:16 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4C3130DF6 for ; Mon, 18 Jun 2018 10:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529341513; x=1529946313; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=fgtfsw7X7xqfjweuZ1Uxk/N9DwQOEZ5fJVimkuKn9HE=; b=D+czDv2FFKppS 7nwdnnRSWuviDuIdP84YtGP50QN/P1u4tcv8JaH9STaE36T/rLIS05/w9gYQc9wE qxiejCEw4prPSmW9cKe/H2k5XzDex0kNiPVdyEJK1ETNHkDIzIwwaybd1bC6p4yR 6Qne0/8EIrIN6USZfDxzxRraGzo5TQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 18 Jun 2018 19:05:13 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 18 Jun 2018 19:05:12 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005791515.msg for ; Mon, 18 Jun 2018 19:05:12 +0200 X-MDRemoteIP: 2001:470:1f09:495:856b:9101:ef3d:cfb7 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 18 Jun 2018 19:05:12 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1707576638=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Mon, 18 Jun 2018 19:05:08 +0200 From: JORDI PALET MARTINEZ To: CC: "v6ops@ietf.org" Message-ID: <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:05:20 -0000 Hi Med, Thanks a lot for your inputs. I've few comments: 1) The requirements language is the same as it was used in RFC7084. We beli= eve it makes a lot of sense to follow that. 2) Some of the comments are related to the usage of expressions such as ser= vices vs servers, transition vs service continuity, etc. The authors consid= er that it is good to use those interchangeable wordings, because for examp= le, if we don't mention transition, a reader may be confused understanding = that this is not regarding transition but a new problem "service continuity= ". Anyway, we will take a look again into this, and also seek for other com= ments from the WG.=20 3) Will clarify anything that doesn't parse easily from your inputs. 4) You're right regarding the numbering of new General and LAN requirements= , there is no reason now to follow the numbering of RFC7084, we will start = from 1. 5) We believe that it makes sense that in the DEFAULT config, according wit= h the discussion in the list, transition is disabled, so we avoid possible = conflicts, unless the ISP turns it on (following RFC8026) or the user (by m= eans of GUI or CLI). 6) The code considerations section was requested in v6ops to be keep as par= t of the document, not an annex. We are happy to change that again if that'= s the WG decision. We will wait a few extra days for any further inputs before submitting a ne= w version (before the cut-off). Thanks ! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: lunes, 18 de junio de 2018, 14:27 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Hi Jordi,=20 =20 FWIW, please find some comments to this draft at:=20 =20 pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft= -ietf-v6ops-transition-ipv4aas-03-rev%20Med.pdf=20 doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-= ietf-v6ops-transition-ipv4aas-03-rev%20Med.doc=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET = MARTINEZ > Envoy=C3=A9 : samedi 16 juin 2018 08:57 > =C3=80 : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 3.txt >=20 > Hi all, >=20 >=20 >=20 > As indicated a couple of day ago, we have updated this document, so i= nstead > of an update of RFC8026 and a new option code, we only need to ask IA= NA to > use a NAT64 existing one for the RFC8026 priority table. >=20 >=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition- > ipv4aas/?include_text=3D1 >=20 >=20 >=20 > Let's know any comments you have. >=20 >=20 >=20 > Thanks! >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de >=20 > Fecha: s=C3=A1bado, 16 de junio de 2018, 8:43 >=20 > Para: >=20 > CC: >=20 > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.tx= t >=20 >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Draft= s > directories. >=20 > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 >=20 >=20 > Title : Requirements for IPv6 Customer Edge Rou= ters to > Support IPv4 Connectivity as-a-Service >=20 > Authors : Jordi Palet Martinez >=20 > Hans M.-H. Liu >=20 > Masanobu Kawashima >=20 > Filename : draft-ietf-v6ops-transition-ipv4aas-03.txt >=20 > Pages : 20 >=20 > Date : 2018-06-15 >=20 >=20 >=20 > Abstract: >=20 > This document specifies the IPv4 service continuity requiremen= ts for >=20 > an IPv6 Customer Edge (CE) router, either provided by the serv= ice >=20 > provider or thru the retail market. >=20 >=20 >=20 > Specifically, this document extends the "Basic Requirements fo= r IPv6 >=20 > Customer Edge Routers" in order to allow the provisioning of I= Pv6 >=20 > transition services for the support of "IPv4 as-a-Service" (IP= v4aaS) >=20 > by means of new transition mechanisms. The document only cove= rs >=20 > transition technologies for delivering IPv4 in IPv6-only acces= s >=20 > networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as re= quired >=20 > in a world where IPv4 addresses are no longer available, so ho= sts in >=20 > the customer LANs with IPv4-only or IPv6-only applications or >=20 > devices, requiring to communicate with IPv4-only services at t= he >=20 > Internet, are still able to do so. >=20 >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4= aas/ >=20 >=20 >=20 > There are also htmlized versions available at: >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-0= 3 >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition= - > ipv4aas-03 >=20 >=20 >=20 > A diff from the previous version is available at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-i= pv4aas-03 >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission >=20 > until the htmlized version and diff are available at tools.ietf.o= rg. >=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be > considered a criminal offense. If you are not the intended recipient = be aware > that any disclosure, copying, distribution or use of the contents of = this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply = to the > original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 18 12:11: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 79350130E30 for ; Mon, 18 Jun 2018 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMl9ta6Ga_TB for ; Mon, 18 Jun 2018 12:11:18 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AD1130E29 for ; Mon, 18 Jun 2018 12:11:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w5IJBHAM024185; Mon, 18 Jun 2018 12:11:17 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w5IJBEvr024125 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 18 Jun 2018 12:11:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Jun 2018 12:11:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Mon, 18 Jun 2018 12:11:14 -0700 From: "Templin (US), Fred L" To: Erik Nygren CC: v6ops list Thread-Topic: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update Thread-Index: AdP3gG5+uFo5RHF/RMmMgf6+VRvj7QNqWKQAAIIpcHA= Date: Mon, 18 Jun 2018 19:11:13 +0000 Message-ID: <60f465d4d74a476bb237e12fe78878b3@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_60f465d4d74a476bb237e12fe78878b3XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 19:11:23 -0000 --_000_60f465d4d74a476bb237e12fe78878b3XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpaywNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlc2UgY29tbWVudHMuIFNlZSBiZWxv dyBmb3IgcmVzcG9uc2VzOg0KDQpGcm9tOiBueWdyZW5AZ21haWwuY29tIFttYWlsdG86bnlncmVu QGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEVyaWsgTnlncmVuDQpTZW50OiBGcmlkYXksIEp1bmUg MTUsIDIwMTggMjoyNCBQTQ0KVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFt2Nm9wc10gSVB2NiBQcmVmaXggRGVsZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10ZW1wbGlu LXY2b3BzLXBkaG9zdCcpIC0gZHJhZnQgdXBkYXRlDQoNCkkgdGhpbmsgdGhpcyBpcyBleHRyZW1l bHkgdXNlZnVsIHdvcmsuICBTb21lIGFkZGl0aW9uYWwgdGhvdWdodHM6DQoNCiogQ29udGFpbmVy IHN5c3RlbXMgKGVnLCBEb2NrZXIpIGFyZSBhbiBpbXBvcnRhbnQgaWxsdXN0cmF0aXZlIHVzZS1j YXNlIGhlcmUgd29ydGggbWVudGlvbmluZyBpbiBhZGRpdGlvbiB0byBWTXMuDQogIEZvciBleGFt cGxlLCBzZWUgdGhlIERvY2tlciBJUHY2IGltcGxlbWVudGF0aW9uIG5vdGVzIGRlc2NyaWJlIHNv bWV0aGluZyB2ZXJ5IHNpbWlsYXIgdG8NCiAgd2hhdCB3ZSBhcmUgZGVzY3JpYmluZyBoZXJlOg0K ICAgICBodHRwczovL2RvY3MuZG9ja2VyLmNvbS92MTcuMDkvZW5naW5lL3VzZXJndWlkZS9uZXR3 b3JraW5nL2RlZmF1bHRfbmV0d29yay9pcHY2Lw0KICBJdCBhc3N1bWVzIGVhY2ggRG9ja2VyIHNl cnZlciBoYXMgaXRzIG93biBwcmVmaXggKGVnLCBhdCBsZWFzdCAvODAgYnV0IG1hbnkgb2YgdGhl IGV4YW1wbGVzIGFyZSAvNjQpDQogIHRoYXQgaXQgYXNzaWducyB0byBjb250YWluZXJzIG91dCBv Zi4gIFRoZXkgZ2l2ZSB0d28gZXhhbXBsZXMsIG9uZSBmb3IgTkQgcHJveHlpbmcNCiAgYW5kIG9u ZSBmb3IgbmV4dC1ob3Agcm91dGluZy4gIFRoZSBsYWNrIG9mIFBELWhvc3QgbW9kZWwgc3VwcG9y dCBpbiBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycw0KICBzdWNoIGFzIEFXUyBtYWtlcyBpdCBtdWNo IGhhcmRlciB0byBkZXBsb3kgSVB2NiBhbmQgRG9ja2VyIG9uIHNvbWV0aGluZyBsaWtlIEFXUw0K ICB3aXRob3V0IHJlc29ydGluZyB0byBob3JyaWJsZSBOQVQ2NiBoYWNrcy4NCg0KDQoNCj4+IFll cywgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIG1lbnRpb24gQ29udGFpbmVyIHN5c3RlbXMg c3VjaCBhcyBEb2NrZXIgdGhhdCBjb3VsZA0KDQo+PiBiZSBleHBlY3RlZCB0byBvY2N1ciBpbiBk b3duc3RyZWFtIGludGVybmFsIHZpcnR1YWwgbmV0d29ya3Mgc2VydmljZWQgaW4gdGhlIGNsYXNz aWMNCg0KPj4gcm91dGluZyBtb2RlbC4gSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGFsc28g c2F5IHRoYXQgdGhpcyBzb3J0IG9mIHByZWZpeCBkZWxlZ2F0aW9uDQoNCj4+IGF2b2lkcyB0aGUg bmVlZCBmb3IgTkFUNjYgaW4gZG93bnN0cmVhbSBuZXR3b3JrcyDigJMgdGhhdCBpcyBhbiBpbXBv cnRhbnQgYXNwZWN0DQoNCj4+IG9mIHRoZSBtb2RlbHMuDQoNCiogQW5vdGhlciBnb29kIGlsbHVz dHJhdGl2ZSB1c2UtY2FzZSBleGFtcGxlIG1pZ2h0IGJlIGltcGxlbWVudGluZyBhIE5BVDY0IG9y IHNpbWlsYXIgc2VydmljZS4NCg0KPj4gTm90IHN1cmUgaG93IHlvdSBtZWFuIGJ5IGltcGxlbWVu dGluZyBOQVQ2NCDigJMgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgaXMgSVB2Ng0KPj4gb25s eS4gRG8geW91IHNlZSBhIHJlYXNvbiBOQVQ2NCBzaG91bGQgY29tZSBpbnRvIHRoaXMgZG9jdW1l bnQ/DQoNCiogUGVyaGFwcyB0YWxrIG1vcmUgKGluIHRoZSBpbnRyb2R1Y3Rpb24sIGlmIG5vdCBl bHNld2hlcmU/KSBhYm91dCB3aGF0IGFkZHJlc3NlcyBnZXQNCiAgdXNlZCBmb3IgdGhlIG5leHQt aG9wIHdoZW4gRiBpcyB0YWxraW5nIHRvIFIsIGluLXRlcm1zIG9mIHdoZW4gaXQgaXMgdXNpbmcg YSBsaW5rLWxvY2FsDQogIHZzIGdsb2JhbC11bmljYXN0IGFkZHJlc3Mgb24gUi4gIFRoZXJlIGFy ZSBsaWtlbHkgdXNlLWNhc2VzIGZvciBib3RoPw0KDQo+PiBGIGFuZCBSIGFyZSBhc3N1bWVkIHRv IGJlIG9uIHRoZSBzYW1lIGxpbmssIGJ1dCBJIGNhbiBtYWtlIHRoaXMgbW9yZSBjbGVhciBpbiB0 aGUNCj4+IGRvY3VtZW50LiBCZWNhdXNlIHRoZXkgYXJlIG9uIHRoZSBzYW1lIGxpbmssIElQdjYg bGluay1sb2NhbCBhZGRyZXNzaW5nIG9uIHRoZQ0KPj4gbGluayBjYW4gYmUgYXNzdW1lZCBmb3Ig RiBhdCBsZWFzdCBhbmQgcHJvYmFibHkgYWxzbyBmb3IgUi4gSXQgaXMgdHJ1ZSB0aGF0IFIgY291 bGQNCj4+IGF1dG9jb25maWd1cmUgYSBnbG9iYWwgYWRkcmVzcyBmb3IgaXRzZWxmIG9uIHRoZSBG PC0+UiBsaW5rLiBCdXQsIFByZWZpeCBEZWxlZ2F0aW9uDQo+PiBtYWludGVuYW5jZSBleGNoYW5n ZXMgd291bGQgYmUgYmFzZWQgb24gdGhlIHNhbWUgbGluay1sb2NhbCBhZGRyZXNzZXMgdXNlZA0K Pj4gdG8gcHJvY3VyZSB0aGUgaW5pdGlhbCBQcmVmaXggRGVsZWdhdGlvbi4NCg0KKiBTZWN0aW9u IDggY291bGQgdXNlIHNvbWUgYmV0dGVyIGV4YW1wbGVzIGFzIHdlbGwgYXMgc29tZSBjbGFyaWZp Y2F0aW9ucyBmb3IgcmVhZGFiaWxpdHkuDQogIEZvciBleGFtcGxlLCB3aGVuIHNheWluZyAiV2hl biBhIG5vZGUgcmVjZWl2ZXMgYSBzaGFyZWQgb3IgaW5kaXZpZHVhbCBwcmVmaXgiDQogIGl0IHNo b3VsZCBzYXkgb3ZlciB3aGF0IHByb3RvY29sIG9yIHR5cGUgb2YgbWVzc2FnZS4NCg0KPj4gUGVy aGFwcyBzYXk6IOKAnGUuZy4sIHZpYSBhIFBJTyBpbmNsdWRlZCBpbiBhbiBSQSBtZXNzYWdl4oCd ID8NCg0KICBBbmQgZm9yICJUaGUgbm9kZSBmdXJ0aGVyIGRvZXMgbm90IHBlcmZvcm0gdGhlDQog SVB2NiBORCBhZGRyZXNzIHJlc29sdXRpb24gZnVuY3Rpb24gb3ZlciB1cHN0cmVhbSBpbnRlcmZh Y2VzIg0KIHRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCBhcyBmb3IganVzdCBiZWluZyBmb3IgYWRk cmVzc2VzIHdpdGhpbiB0aGUgZGVsZWdhdGVkIHByZWZpeC4NCg0KPj4gQ29ycmVjdCAtIHdpbGwg Zml4Lg0KDQogSXQgd291bGQgYWxzbyBoZWxwIHRvIGNsYXJpZnkgd2hpY2ggY2FzZXMgdGhlIGRl bGVnYXRlZCBwcmVmaXhlcw0KIGJlaW5nIGRpc2N1c3NlZCBhcmUgZm9yIHRoYXQgbm9kZSBvciBm b3IgYSBub2RlIGl0IHdpc2hlcyB0byB0YWxrIHRvLg0KICAoaWUsIGNsYXJpZnkgdGhlIGJlaGF2 aW9yIGZvciBhIG5vZGUgdGhhdCBzaGFyZXMgYW4gdXBzdHJlYW0gaW50ZXJmYWNlL2xpbmsNCiAg d2l0aCBvbmUgb3IgbW9yZSBob3N0cyB0aGF0IGhhdmUgZGVsZWdhdGVkIHByZWZpeGVzLikNCg0K Pj4gVGhpcyBpcyBpbmRlZWQgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24gdG8gZW1waGFzaXpl LCBhbmQgd291bGQgYmVuZWZpdCBmcm9tDQo+PiBhbiBhZGRpdGlvbmFsIHNlbnRlbmNlIGF0IHRo ZSBiZWdpbm5pbmcgb2YgdGhlIHRoaXJkIHBhcmFncmFwaCBpbiB0aGF0IFNlY3Rpb24uDQo+PiBI b3cgZG9lcyB0aGlzIHNvdW5kOg0KPj4NCj4+ICAg4oCcTWFueSByZXF1ZXN0aW5nIG5vZGVzIHRo YXQgcmVjZWl2ZSBQcmVmaXggRGVsZWdhdGlvbnMgbWF5IGJlIGNvbm5lY3RlZA0KPj4gICAgIHRv IHRoZSBzYW1lIChzaGFyZWQpIHVwc3RyZWFtIGxpbmssIGJ1dCBtYXkgbm90IGJlIHJ1bm5pbmcg YSBkeW5hbWljDQo+PiAgICAgcm91dGluZyBwcm90b2NvbCBvdmVyIHRoYXQgbGluay7igJ0NCg0K KiBGb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNvbWUgYXR0YWNrcyBtYXkgc3RpbGwgYmUg cG9zc2libGUgdGhyb3VnaA0KICBvbi1uZXQgaG9zdHMuICAoZWcsIGlmIHRoZSBsb2NhbCBuZXR3 b3JrIGNvbnRhaW5zIGFuIG9wZW4gcmVjdXJzaXZlIEROUyByZXNvbHZlcg0KICBpdCBjb3VsZCBi ZSB0cmlja2VkIGludG8gbWFraW5nIGxvdHMgb2Ygb24tdXBzdHJlYW0gTkQgcmVxdWVzdHMgZm9y IHRoZSBwcmVmaXguKQ0KICBUaGlzIG1heSBmYWxsIGludG8gZXhpc3RpbmcgTkQgY29uc2lkZXJh dGlvbnMsIGJ1dCBpcyBhIGNvcm5lciBjYXNlIHdoZXJlDQogIHRoZSBwcmVmaXggZGVsZWdhdGlv biBtYXkgbm90IGhlbHAgZW5vdWdoPw0KDQo+PiBJIGFtIG9wZW4gdG8gYW55IHRleHQgc3VnZ2Vz dGlvbnMgeW91IG1heSBoYXZlIGZvciB0aGlzLg0KDQoqIFN0YXRpYyBwcm92aXNpb25pbmcgcGx1 cyBpQkdQIG5leHQtaG9wIGFkdmVydGlzZW1lbnRzIGlzIGFub3RoZXINCiAgcHJvdmlzaW9uaW5n IG1lY2hhbmlzbSB0aGF0IEkndmUgc2VlbiB1c2VkLiAgIChGb3IgZXhhbXBsZSwgdG8gYXNzaWdu IDI1NiAvNjQgZGVsZWdhdGVkIHByZWZpeGVzDQogIG91dCBvZiBhIHNpbmdsZSBzdGF0aWNhbGx5 IGFzc2lnbmVkIC81NiB0byByb3V0ZSB0byBORC1tYW5hZ2VkIGdsb2JhbC11bmljYXN0IHNlcnZp Y2UgYWRkcmVzc2VzLg0KICBUaGlzIGhhcyB3b3JrZWQgd2VsbCBvdGhlciB0aGFuIGJlaW5nIGEg cGFpbiB0byBjb252aW5jZSBuZXR3b3JrcyB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdG8gc3VwcG9y dC4pDQoNCj4+IFllcywgdGhpcyBiZWxvbmdzIGFzIGFuIGV4YW1wbGUgaW4gU2VjdGlvbiAxMC4N Cg0KKiBJcyBpdCB3b3JrIG1lbnRpb25pbmcgdXNlLWNhc2VzIGZvciAic2hhcmVkIGRlbGVnYXRl ZCBwcmVmaXhlcyIsDQogIG9yIGRvZXMgdGhhdCBhZGQgY29uZnVzaW9uIGFuZCBzaG91bGQgYmUg YSB0b3BpYyBmb3IgYSBmdXR1cmUgZHJhZnQ/DQogIEluIHBhcnRpY3VsYXIgd2hlcmUgbm9kZXMg c2hhcmUgYSBkZWxlZ2F0ZWQgcHJlZml4IGFuZCB0aGUgZmlyc3QtaG9wIHJvdXRlciBGDQogIGxv YWQtYmFsYW5jZXMgYmV0d2VlbiB0aGVtLCBzdWNoIGFzIHZpYSBFQ01QLiAgQSB1c2UtY2FzZSBt aWdodCBiZSBhIE5BVDY0DQogIG9yIGx3NG82IGRlY2Fwc3VsYXRpb24gc2VydmljZSB3aGVyZSBv bmUgcHJlZml4IGlzIGVmZmVjdGl2ZWx5IGRlbGVnYXRlZCB0byBhIHNldA0KICBvZiBob3N0cyB3 aGljaCBlYWNoIGhhdmUgaW50ZW50aW9uYWxseSBkdXBsaWNhdGUgYWRkcmVzc2VzLg0KICBUaGUg cHJpbWFyeSBjaGFuZ2UgZW5kcyB1cCBiZWluZyB3aXRoIE5ELg0KDQo+PiBWZXJ5IGludGVyZXN0 aW5nIHBvaW50LCBidXQgSSB0aGluayBiZXlvbmQgdGhlIHNjb3BlIG9mIHdoYXQgd2UgYXJlIGRv aW5nIGhlcmUuDQo+PiBUaGUgbm9taW5hbCBleGFtcGxlIHRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0 byBob25vciBpcyBSRkMzNjMzLXN0eWxlIFBEIChvcg0KPj4gYW55IG90aGVyIGNvbXBhcmFibGUg c2VydmljZSkgd2hlcmUgYSBwcmVmaXggaXMgZGVsZWdhdGVkIHRvIG9uZSBhbmQgb25seSBvbmUN Cj4+IHJlcXVlc3Rpbmcgbm9kZS4gUGVyaGFwcyB0aGlzIGNvdWxkIGdvIGludG8gYSBzZXBhcmF0 ZSBkb2N1bWVudCwgYW5kL29yIHdlDQo+PiBjb3VsZCBhZGQgYSBmZXcgd29yZHMgaGVyZSB0byBk ZXNjcmliZSB0aGUgdXNlIGNhc2UgYnV0IGRlY2xhcmUgaXQgb3V0IG9mIHNjb3BlPw0KDQpUaGFu a3MgLSBGcmVkDQoNCkJlc3QsIEVyaWsNCg0KDQoNCk9uIFR1ZSwgTWF5IDI5LCAyMDE4IGF0IDM6 MTMgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1h aWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpTZWUgYmVsb3cgZm9yIGEg ZHJhZnQgdXBkYXRlIHRvICJJUHY2IFByZWZpeCBEZWxlZ2F0aW9uIE1vZGVscyAoJ2RyYWZ0LXRl bXBsaW4tdjZvcHMtcGRob3N0JykuDQpUaGlzIHZlcnNpb24gKC0yMCkgdXBkYXRlcyBmaWd1cmUg MSBhbmQgYWRkcyBpbmZvcm1hdGl2ZSB0ZXh0IG9uIHRoZSByZWxhdGlvbiB0byBtdWx0aS1hZGRy ZXNzaW5nDQooUkZDNzkzNCBhbmQgUkZDODI3MykuIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQu DQoNCkZyZWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEktRC1Bbm5vdW5j ZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1heSAy OSwgMjAxOCAxMjowMiBQTQ0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnPg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtdGVtcGxpbi12Nm9w cy1wZGhvc3QtMjAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAgICAg VGl0bGUgICAgICAgICAgIDogSVB2NiBQcmVmaXggRGVsZWdhdGlvbiBNb2RlbHMNCiAgICAgICAg QXV0aG9yICAgICAgICAgIDogRnJlZCBMLiBUZW1wbGluDQogICAgICAgIEZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwLnR4dA0KICAgICAgICBQYWdlcyAgICAg ICAgICAgOiAxNA0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE4LTA1LTI5DQoNCkFic3Ry YWN0Og0KICAgSVB2NiBwcmVmaXhlcyBhcmUgdHlwaWNhbGx5IGRlbGVnYXRlZCB0byByZXF1ZXN0 aW5nIHJvdXRlcnMgd2hpY2gNCiAgIGFzc2lnbiB0aGVtIHRvIHRoZWlyIGRvd25zdHJlYW0tYXR0 YWNoZWQgbGlua3MgYW5kIG5ldHdvcmtzLiAgVGhlDQogICByZXF1ZXN0aW5nIG5vZGUgY2FuIHBy b3Zpc2lvbiB0aGUgcHJlZml4IGFjY29yZGluZyB0byB3aGV0aGVyIGl0IGFjdHMNCiAgIGFzIGEg cm91dGVyIG9uIGJlaGFsZiBvZiBhbnkgZG93bnN0cmVhbSBuZXR3b3JrcyBhbmQvb3IgYXMgYSBo b3N0IG9uDQogICBiZWhhbGYgb2YgaXRzIGxvY2FsIGFwcGxpY2F0aW9ucy4gIEluIHRoZSBsYXR0 ZXIgY2FzZSwgdGhlIHJlcXVlc3RpbmcNCiAgIG5vZGUgY2FuIHVzZSBwb3J0aW9ucyBvZiB0aGUg ZGVsZWdhdGVkIHByZWZpeCBmb3IgaXRzIG93biBtdWx0aS0NCiAgIGFkZHJlc3NpbmcgcHVycG9z ZXMuICBUaGlzIGRvY3VtZW50IHRoZXJlZm9yZSBjb25zaWRlcnMgcHJlZml4DQogICBkZWxlZ2F0 aW9uIG1vZGVscyBmb3IgYm90aCB0aGUgY2xhc3NpYyByb3V0aW5nIGFuZCBtdWx0aS1hZGRyZXNz aW5nDQogICB1c2UgY2FzZXMuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10ZW1wbGluLXY2b3BzLXBkaG9zdC8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv bnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRlbXBs aW4tdjZvcHMtcGRob3N0LTIwDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBp ZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9y aWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3Jn PG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg0K --_000_60f465d4d74a476bb237e12fe78878b3XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkxMDcyODUyNDsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgzMjE4MTczNCAtMTY3MjU1MDMyNCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SGkgRXJpayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZXNlIGNvbW1lbnRzLiBTZWUgYmVs b3cgZm9yIHJlc3BvbnNlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBueWdyZW5AZ21haWwuY29tIFttYWlsdG86bnln cmVuQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpayBOeWdyZW48YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBKdW5lIDE1LCAyMDE4IDI6MjQgUE08YnI+DQo8Yj5Ubzo8L2I+IFRl bXBsaW4gKFVTKSwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIElQdjYgUHJlZml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJh ZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnKSAtIGRyYWZ0IHVwZGF0ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlz IGlzIGV4dHJlbWVseSB1c2VmdWwgd29yay4mbmJzcDsgU29tZSBhZGRpdGlvbmFsIHRob3VnaHRz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4q IENvbnRhaW5lciBzeXN0ZW1zIChlZywgRG9ja2VyKSBhcmUgYW4gaW1wb3J0YW50IGlsbHVzdHJh dGl2ZSB1c2UtY2FzZSBoZXJlIHdvcnRoIG1lbnRpb25pbmcgaW4gYWRkaXRpb24gdG8gVk1zLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IEZvciBleGFtcGxlLCBzZWUgdGhlIERvY2tlciBJUHY2IGltcGxlbWVudGF0aW9uIG5vdGVzIGRl c2NyaWJlIHNvbWV0aGluZyB2ZXJ5IHNpbWlsYXIgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB3aGF0IHdlIGFyZSBkZXNjcmliaW5n IGhlcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kb2NzLmRvY2tlci5j b20vdjE3LjA5L2VuZ2luZS91c2VyZ3VpZGUvbmV0d29ya2luZy9kZWZhdWx0X25ldHdvcmsvaXB2 Ni8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZG9jcy5kb2NrZXIuY29tL3YxNy4wOS9lbmdp bmUvdXNlcmd1aWRlL25ldHdvcmtpbmcvZGVmYXVsdF9uZXR3b3JrL2lwdjYvPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEl0IGFz c3VtZXMgZWFjaCBEb2NrZXIgc2VydmVyIGhhcyBpdHMgb3duIHByZWZpeCAoZWcsIGF0IGxlYXN0 IC84MCBidXQgbWFueSBvZiB0aGUgZXhhbXBsZXMgYXJlIC82NCk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB0aGF0IGl0IGFzc2lnbnMg dG8gY29udGFpbmVycyBvdXQgb2YuJm5ic3A7IFRoZXkgZ2l2ZSB0d28gZXhhbXBsZXMsIG9uZSBm b3IgTkQgcHJveHlpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyBhbmQgb25lIGZvciBuZXh0LWhvcCByb3V0aW5nLiZuYnNwOyBUaGUg bGFjayBvZiBQRC1ob3N0IG1vZGVsIHN1cHBvcnQgaW4gY2xvdWQgc2VydmljZSBwcm92aWRlcnM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyBzdWNoIGFzIEFXUyBtYWtlcyBpdCBtdWNoIGhhcmRlciB0byBkZXBsb3kgSVB2NiBhbmQgRG9j a2VyIG9uIHNvbWV0aGluZyBsaWtlIEFXUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHdpdGhvdXQgcmVzb3J0aW5nIHRvIGhvcnJpYmxl IE5BVDY2IGhhY2tzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNv LXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmls bC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IFllcywgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRv IG1lbnRpb24gQ29udGFpbmVyDQogc3lzdGVtcyBzdWNoIGFzIERvY2tlciB0aGF0IGNvdWxkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10 ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6 MTAwLjAlIj4mZ3Q7Jmd0OyBiZSBleHBlY3RlZCB0byBvY2N1ciBpbiBkb3duc3RyZWFtIGludGVy bmFsIHZpcnR1YWwNCiBuZXR3b3JrcyBzZXJ2aWNlZCBpbiB0aGUgY2xhc3NpYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwt ZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+ Jmd0OyZndDsgcm91dGluZyBtb2RlbC4gSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGFsc28g c2F5DQogdGhhdCB0aGlzIHNvcnQgb2YgcHJlZml4IGRlbGVnYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwt Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsm Z3Q7IGF2b2lkcyB0aGUgbmVlZCBmb3IgTkFUNjYgaW4gZG93bnN0cmVhbSBuZXR3b3Jrcw0KIOKA kyB0aGF0IGlzIGFuIGltcG9ydGFudCBhc3BlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5 Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IG9mIHRoZSBt b2RlbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qIEFub3RoZXIgZ29vZCBpbGx1c3RyYXRpdmUgdXNlLWNhc2UgZXhhbXBsZSBt aWdodCBiZSBpbXBsZW1lbnRpbmcgYSBOQVQ2NCBvciBzaW1pbGFyIHNlcnZpY2UuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0 eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj4mZ3Q7Jmd0OyBOb3Qgc3VyZSBob3cgeW91 IG1lYW4gYnkgaW1wbGVtZW50aW5nIE5BVDY0IOKAkyB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dCBpcyBJUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6 IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IG9u bHkuIERvIHlvdSBzZWUgYSByZWFzb24gTkFUNjQgc2hvdWxkIGNvbWUgaW50byB0aGlzIGRvY3Vt ZW50Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qIFBlcmhhcHMgdGFsayBtb3JlIChpbiB0aGUgaW50cm9kdWN0aW9uLCBpZiBu b3QgZWxzZXdoZXJlPykgYWJvdXQgd2hhdCBhZGRyZXNzZXMgZ2V0DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB1c2VkIGZvciB0aGUg bmV4dC1ob3Agd2hlbiBGIGlzIHRhbGtpbmcgdG8gUiwgaW4tdGVybXMgb2Ygd2hlbiBpdCBpcyB1 c2luZyBhIGxpbmstbG9jYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyB2cyBnbG9iYWwtdW5pY2FzdCBhZGRyZXNzIG9uIFIuJm5ic3A7 IFRoZXJlIGFyZSBsaWtlbHkgdXNlLWNhc2VzIGZvciBib3RoPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5 Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0Zmls bC1maWxsLWFscGhhOjEwMC4wJSI+Jmd0OyZndDsgRiBhbmQgUiBhcmUgYXNzdW1lZCB0byBiZSBv biB0aGUgc2FtZSBsaW5rLCBidXQgSSBjYW4gbWFrZSB0aGlzIG1vcmUgY2xlYXIgaW4gdGhlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28t c3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IGRvY3VtZW50LiBCZWNh dXNlIHRoZXkgYXJlIG9uIHRoZSBzYW1lIGxpbmssIElQdjYgbGluay1sb2NhbCBhZGRyZXNzaW5n IG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMy RjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj4mZ3Q7Jmd0OyBsaW5r IGNhbiBiZSBhc3N1bWVkIGZvciBGIGF0IGxlYXN0IGFuZCBwcm9iYWJseSBhbHNvIGZvciBSLiBJ dCBpcyB0cnVlIHRoYXQgUiBjb3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0Zmls bC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAl Ij4mZ3Q7Jmd0OyBhdXRvY29uZmlndXJlIGEgZ2xvYmFsIGFkZHJlc3MgZm9yIGl0c2VsZiBvbiB0 aGUgRiZsdDstJmd0O1IgbGluay4gQnV0LCBQcmVmaXggRGVsZWdhdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkY1 NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRm aWxsLWZpbGwtYWxwaGE6MTAwLjAlIj4mZ3Q7Jmd0OyBtYWludGVuYW5jZSBleGNoYW5nZXMgd291 bGQgYmUgYmFzZWQgb24gdGhlIHNhbWUgbGluay1sb2NhbCBhZGRyZXNzZXMgdXNlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj4mZ3Q7Jmd0OyB0byBwcm9jdXJlIHRoZSBpbml0 aWFsIFByZWZpeCBEZWxlZ2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTZWN0aW9uIDggY291bGQgdXNlIHNvbWUgYmV0 dGVyIGV4YW1wbGVzIGFzIHdlbGwgYXMgc29tZSBjbGFyaWZpY2F0aW9ucyBmb3IgcmVhZGFiaWxp dHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgRm9yIGV4YW1wbGUsIHdoZW4gc2F5aW5nICZxdW90O1doZW4gYSBub2RlIHJlY2VpdmVz IGEgc2hhcmVkIG9yIGluZGl2aWR1YWwgcHJlZml4JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgaXQgc2hvdWxkIHNheSBvdmVy IHdoYXQgcHJvdG9jb2wgb3IgdHlwZSBvZiBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nztt c28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1m aWxsLWFscGhhOjEwMC4wJSI+Jmd0OyZndDsgUGVyaGFwcyBzYXk6IOKAnGUuZy4sIHZpYSBhIFBJ TyBpbmNsdWRlZCBpbiBhbiBSQSBtZXNzYWdl4oCdID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBBbmQg Zm9yICZxdW90O1RoZSBub2RlIGZ1cnRoZXIgZG9lcyBub3QgcGVyZm9ybSB0aGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0lQdjYgTkQg YWRkcmVzcyByZXNvbHV0aW9uIGZ1bmN0aW9uIG92ZXIgdXBzdHJlYW0gaW50ZXJmYWNlcyZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7dGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGFzIGZvciBqdXN0IGJlaW5nIGZvciBhZGRyZXNz ZXMgd2l0aGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28t c3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxs LWFscGhhOjEwMC4wJSI+Jmd0OyZndDsgQ29ycmVjdCAtIHdpbGwgZml4LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7SXQgd291bGQgYWxzbyBoZWxwIHRvIGNsYXJpZnkgd2hpY2ggY2FzZXMgdGhlIGRlbGVn YXRlZCBwcmVmaXhlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7YmVpbmcgZGlzY3Vzc2VkIGFyZSBmb3IgdGhhdCBub2RlIG9yIGZvciBh IG5vZGUgaXQgd2lzaGVzIHRvIHRhbGsgdG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgKGllLCBjbGFyaWZ5IHRoZSBiZWhhdmlvciBm b3IgYSBub2RlIHRoYXQgc2hhcmVzIGFuIHVwc3RyZWFtIGludGVyZmFjZS9saW5rPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgd2l0aCBv bmUgb3IgbW9yZSBob3N0cyB0aGF0IGhhdmUgZGVsZWdhdGVkIHByZWZpeGVzLik8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5 bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IFRoaXMgaXMgaW5kZWVkIGFu IGltcG9ydGFudCBjb25zaWRlcmF0aW9uIHRvIGVtcGhhc2l6ZSwgYW5kIHdvdWxkIGJlbmVmaXQg ZnJvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1 OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj4mZ3Q7Jmd0OyBhbiBhZGRp dGlvbmFsIHNlbnRlbmNlIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHRoaXJkIHBhcmFncmFwaCBp biB0aGF0IFNlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwt Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsm Z3Q7IEhvdyBkb2VzIHRoaXMgc291bmQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRm aWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAu MCUiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZp bGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZn dDsmZ3Q7ICZuYnNwOyZuYnNwO+KAnE1hbnkgcmVxdWVzdGluZyBub2RlcyB0aGF0IHJlY2VpdmUg UHJlZml4IERlbGVnYXRpb25zIG1heSBiZSBjb25uZWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28t c3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxs LWFscGhhOjEwMC4wJSI+Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dG8gdGhlIHNh bWUgKHNoYXJlZCkgdXBzdHJlYW0gbGluaywgYnV0IG1heSBub3QgYmUgcnVubmluZyBhIGR5bmFt aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3 O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+Jmd0OyZndDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7cm91dGluZyBwcm90b2NvbCBvdmVyIHRoYXQgbGluay7igJ0NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KiBGb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNvbWUgYXR0YWNrcyBtYXkgc3RpbGwgYmUg cG9zc2libGUgdGhyb3VnaDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IG9uLW5ldCBob3N0cy4mbmJzcDsgKGVnLCBpZiB0aGUgbG9jYWwg bmV0d29yayBjb250YWlucyBhbiBvcGVuIHJlY3Vyc2l2ZSBETlMgcmVzb2x2ZXI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpdCBjb3Vs ZCBiZSB0cmlja2VkIGludG8gbWFraW5nIGxvdHMgb2Ygb24tdXBzdHJlYW0gTkQgcmVxdWVzdHMg Zm9yIHRoZSBwcmVmaXguKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IFRoaXMgbWF5IGZhbGwgaW50byBleGlzdGluZyBORCBjb25zaWRl cmF0aW9ucywgYnV0IGlzIGEgY29ybmVyIGNhc2Ugd2hlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB0aGUgcHJlZml4IGRlbGVnYXRp b24gbWF5IG5vdCBoZWxwIGVub3VnaD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRl eHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYTox MDAuMCUiPiZndDsmZ3Q7IEkgYW0gb3BlbiB0byBhbnkgdGV4dCBzdWdnZXN0aW9ucyB5b3UgbWF5 IGhhdmUgZm9yIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBTdGF0aWMgcHJvdmlzaW9uaW5nIHBsdXMgaUJH UCBuZXh0LWhvcCBhZHZlcnRpc2VtZW50cyBpcyBhbm90aGVyDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBwcm92aXNpb25pbmcgbWVj aGFuaXNtIHRoYXQgSSd2ZSBzZWVuIHVzZWQuJm5ic3A7Jm5ic3A7IChGb3IgZXhhbXBsZSwgdG8g YXNzaWduIDI1NiAvNjQgZGVsZWdhdGVkIHByZWZpeGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgb3V0IG9mIGEgc2luZ2xlIHN0YXRp Y2FsbHkgYXNzaWduZWQgLzU2IHRvIHJvdXRlIHRvIE5ELW1hbmFnZWQgZ2xvYmFsLXVuaWNhc3Qg c2VydmljZSBhZGRyZXNzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgVGhpcyBoYXMgd29ya2VkIHdlbGwgb3RoZXIgdGhhbiBiZWlu ZyBhIHBhaW4gdG8gY29udmluY2UgbmV0d29ya3MgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRvIHN1 cHBvcnQuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xv cjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+Jmd0OyZndDsg WWVzLCB0aGlzIGJlbG9uZ3MgYXMgYW4gZXhhbXBsZSBpbiBTZWN0aW9uIDEwLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBJcyBp dCB3b3JrIG1lbnRpb25pbmcgdXNlLWNhc2VzIGZvciAmcXVvdDtzaGFyZWQgZGVsZWdhdGVkIHBy ZWZpeGVzJnF1b3Q7LA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgb3IgZG9lcyB0aGF0IGFkZCBjb25mdXNpb24gYW5kIHNob3VsZCBi ZSBhIHRvcGljIGZvciBhIGZ1dHVyZSBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBJbiBwYXJ0aWN1bGFyIHdoZXJlIG5vZGVz IHNoYXJlIGEgZGVsZWdhdGVkIHByZWZpeCBhbmQgdGhlIGZpcnN0LWhvcCByb3V0ZXIgRg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg bG9hZC1iYWxhbmNlcyBiZXR3ZWVuIHRoZW0sIHN1Y2ggYXMgdmlhIEVDTVAuJm5ic3A7IEEgdXNl LWNhc2UgbWlnaHQgYmUgYSBOQVQ2NA0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgb3IgbHc0bzYgZGVjYXBzdWxhdGlvbiBzZXJ2aWNl IHdoZXJlIG9uZSBwcmVmaXggaXMgZWZmZWN0aXZlbHkgZGVsZWdhdGVkIHRvIGEgc2V0DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBv ZiBob3N0cyB3aGljaCBlYWNoIGhhdmUgaW50ZW50aW9uYWxseSBkdXBsaWNhdGUgYWRkcmVzc2Vz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgVGhlIHByaW1hcnkgY2hhbmdlIGVuZHMgdXAgYmVpbmcgd2l0aCBORC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nztt c28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPiZndDsmZ3Q7IFZlcnkgaW50ZXJl c3RpbmcgcG9pbnQsIGJ1dCBJIHRoaW5rIGJleW9uZCB0aGUgc2NvcGUgb2Ygd2hhdCB3ZSBhcmUg ZG9pbmcgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xv cjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+Jmd0OyZndDsg VGhlIG5vbWluYWwgZXhhbXBsZSB0aGlzIGRvY3VtZW50IGludGVuZHMgdG8gaG9ub3IgaXMgUkZD MzYzMy1zdHlsZSBQRCAob3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmls bC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+Jmd0 OyZndDsgYW55IG90aGVyIGNvbXBhcmFibGUgc2VydmljZSkgd2hlcmUgYSBwcmVmaXggaXMgZGVs ZWdhdGVkIHRvIG9uZSBhbmQgb25seSBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4 dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEw MC4wJSI+Jmd0OyZndDsgcmVxdWVzdGluZyBub2RlLiBQZXJoYXBzIHRoaXMgY291bGQgZ28gaW50 byBhIHNlcGFyYXRlIGRvY3VtZW50LCBhbmQvb3Igd2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5Nzttc28tc3R5 bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFs cGhhOjEwMC4wJSI+Jmd0OyZndDsgY291bGQgYWRkIGEgZmV3IHdvcmRzIGhlcmUgdG8gZGVzY3Jp YmUgdGhlIHVzZSBjYXNlIGJ1dCBkZWNsYXJlIGl0IG91dCBvZiBzY29wZT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJG NTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0 ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTc7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBo YToxMDAuMCUiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsIEVyaWs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWF5IDI5LCAy MDE4IGF0IDM6MTMgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgYmVsb3cgZm9yIGEgZHJhZnQgdXBkYXRlIHRvICZxdW90 O0lQdjYgUHJlZml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhv c3QnKS48YnI+DQpUaGlzIHZlcnNpb24gKC0yMCkgdXBkYXRlcyBmaWd1cmUgMSBhbmQgYWRkcyBp bmZvcm1hdGl2ZSB0ZXh0IG9uIHRoZSByZWxhdGlvbiB0byBtdWx0aS1hZGRyZXNzaW5nPGJyPg0K KFJGQzc5MzQgYW5kIFJGQzgyNzMpLiBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Ljxicj4NCjxi cj4NCkZyZWQ8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IEktRC1Bbm5vdW5jZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2UtYm91bmNl c0BpZXRmLm9yZyI+aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiBUdWVzZGF5LCBNYXkgMjksIDIwMTggMTI6MDIg UE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFu bm91bmNlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LXRlbXBs aW4tdjZvcHMtcGRob3N0LTIwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogSVB2NiBQcmVmaXggRGVs ZWdhdGlvbiBNb2RlbHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEZyZWQgTC4gVGVtcGxpbjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwLnR4dDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7OiAxNDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE4LTA1LTI5PGJyPg0KPGJyPg0K QWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO0lQdjYgcHJlZml4ZXMgYXJlIHR5cGljYWxseSBk ZWxlZ2F0ZWQgdG8gcmVxdWVzdGluZyByb3V0ZXJzIHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwO2Fz c2lnbiB0aGVtIHRvIHRoZWlyIGRvd25zdHJlYW0tYXR0YWNoZWQgbGlua3MgYW5kIG5ldHdvcmtz LiZuYnNwOyBUaGU8YnI+DQombmJzcDsgJm5ic3A7cmVxdWVzdGluZyBub2RlIGNhbiBwcm92aXNp b24gdGhlIHByZWZpeCBhY2NvcmRpbmcgdG8gd2hldGhlciBpdCBhY3RzPGJyPg0KJm5ic3A7ICZu YnNwO2FzIGEgcm91dGVyIG9uIGJlaGFsZiBvZiBhbnkgZG93bnN0cmVhbSBuZXR3b3JrcyBhbmQv b3IgYXMgYSBob3N0IG9uPGJyPg0KJm5ic3A7ICZuYnNwO2JlaGFsZiBvZiBpdHMgbG9jYWwgYXBw bGljYXRpb25zLiZuYnNwOyBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSByZXF1ZXN0aW5nPGJyPg0K Jm5ic3A7ICZuYnNwO25vZGUgY2FuIHVzZSBwb3J0aW9ucyBvZiB0aGUgZGVsZWdhdGVkIHByZWZp eCBmb3IgaXRzIG93biBtdWx0aS08YnI+DQombmJzcDsgJm5ic3A7YWRkcmVzc2luZyBwdXJwb3Nl cy4mbmJzcDsgVGhpcyBkb2N1bWVudCB0aGVyZWZvcmUgY29uc2lkZXJzIHByZWZpeDxicj4NCiZu YnNwOyAmbmJzcDtkZWxlZ2F0aW9uIG1vZGVscyBmb3IgYm90aCB0aGUgY2xhc3NpYyByb3V0aW5n IGFuZCBtdWx0aS1hZGRyZXNzaW5nPGJyPg0KJm5ic3A7ICZuYnNwO3VzZSBjYXNlcy48YnI+DQo8 YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10ZW1wbGluLXY2b3BzLXBkaG9zdC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC88L2E+PGJyPg0KPGJy Pg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC0yMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMDwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMDwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRl bXBsaW4tdjZvcHMtcGRob3N0LTIwPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciPkktRC1Bbm5vdW5jZUBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ktZC1hbm5vdW5jZUludGVybmV0LURyYWZ0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8YnI+DQpJbnRlcm5l dC1EcmFmdDwvYT4gZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWw8L2E+PGJyPg0Kb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1z aXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dDwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_60f465d4d74a476bb237e12fe78878b3XCH150608nwnosboeingcom_-- From nobody Mon Jun 18 18:30: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 484CE130E81 for ; Mon, 18 Jun 2018 18:30:30 -0700 (PDT) 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_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU3PHvRVWt1l for ; Mon, 18 Jun 2018 18:30:27 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06A9131006 for ; Mon, 18 Jun 2018 18:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529371827; x=2393285427; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jqhgrki2bMgK1OHA4M8yAodtCPWVavv0Mi8FNiPu4pM=; b=pyjpYM2GIkmoZjcL+ApWltkNIbSii+Cfp/lih5sVpA9v+o4fOLVaeA+7WIdUr5C5 wtjJP1ZTYtzCISFnC882zGCUy4wtcGmu8W0NLaVumsmBrrUZl3a6Xlo8Tm2o8v2L Dc15r/C/Qx/rwkfVlY+TAyaBmi9JsVTwDS7Le8TueN8PDaeFh0aLbufu4xTr3Nfi 83nHgCDZNWZpUoh19vZdBAEUV+xga68M5lAovQ8z1Lt//UEFZA4eBWSyLsB+iP4z n5NKESie+YU2DpvZxdXfGB8C1T+W1oBTRusIAFJYTY7rqQOgRTV2sCQOJC7frHYN GVC/9bpIfjDEMy3u95qaHA==; Received: from relay2.asia.apple.com (relay2.asia.apple.com [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 54.C0.15050.2BC582B5; Mon, 18 Jun 2018 18:30:27 -0700 (PDT) X-AuditID: 11973e11-f0d049e000003aca-c9-5b285cb2aea9 Received: from echium.asia.apple.com ( [17.84.80.65]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 27.72.30791.FAC582B5; Tue, 19 Jun 2018 09:30:23 +0800 (MYT) Received: from [17.192.155.180] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAJ00LKDQUIR340@echium.asia.apple.com>; Tue, 19 Jun 2018 09:30:22 +0800 (SGT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_3961EC25-55C4-4F55-87D4-ABBC0038EC4C" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Jun 2018 18:30:17 -0700 In-reply-to: Cc: Stuart Cheshire , Michelle Cotton via RT , dnsop , IPv6 Operations To: Warren Kumari , Mark Andrews References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUiGHRCQHdzjEa0wbxzEhZ331xmsWhdvZTd 4sqL+ywWp4/tZbY4fOwykwOrR4+8x5IlP5k8Hjx+x+xx+8Yf9gCWKC6blNSczLLUIn27BK6M C0972Qp6tCvefqxrYPym0sXIySEhYCLRfmQFYxcjF4eQwBYmiSWHmxhhEj1TfzNBJOYzSXyY 9o8VwvnEKHFjxgZWkCphAWmJrgt3gWwODjYBLYkDa4xAwrwCNhLTGxpYQMLMAkkS1/riIcIm Erev/WCH6AyReHazH2wXi4CqxKzVV8BsToFgiaOvH7CDrGIWmMEo8f5zDzNIQkTAWWLhtRts EDfMZpKYcO8zC8SlShLTv98GS0gInGGTOPr7HdsERqFZCMtnIVkOYjMLaEssW/iaGaJER2Ly QkZUYQj74/kjTAsY2VYxCuUmZuboZuYZ6SUWFOSk6iXn525iBMXNdDvBHYzHV1kdYhTgYFTi 4dVYrx4txJpYVlyZe4hRmoNFSZxXV0wjWkggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjVDs+ u3kThQzi48I/BTyLPpIaMv/a7/2aenN+3r55iWFa5HWDp3m3jjmfEffiyLu4OOR2SM1fGdYH msUGid9VTolpMWoXTdi+OXvWtz+3/updu5UyRW2Zv+rzfPtwpqmrtp4MnDst3dv+pVWGtnTX gqVvlv+u3pj4tefYK7Zz+s3xjf8bbnZvUGIpzkg01GIuKk4EAK1LZ4B8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUiGBLgqLs+RiPa4PElAYtjd2os7r65zGLR unopu8WVF/dZLE4f28tscfjYZSYHNo+tJ3+wefTIeyxZ8pPJ48Hjd8wet2/8YQ9gjeKySUnN ySxLLdK3S+DKuPC0l62gR7vi7ce6BsZvKl2MnBwSAiYSPVN/M3UxcnEICcxnkvgw7R8rhPOJ UeLGjA2sIFXCAtISXRfuAtkcHGwCWhIH1hiBhHkFbCSmNzSwgISZBZIkrvXFQ4RNJG5f+8EO 0Rki8exmPyOIzSKgKjFr9RUwm1MgWOLo6wfsIKuYBWYwSrz/3MMMkhARcJZYeO0GG8QNs5kk Jtz7zAJxqZLE9O+32SYw8s9C2DcLyT4Qm1lAW2LZwtfMECU6EpMXMqIKQ9gfzx9hWsDItopR tCg1J7HSSC+xODNRL7GgICdVLzk/dxMjKAaCTgjsYJx1yOAQowAHoxIPr3m0RrQQa2JZcWXu IUYJDmYlEd7kX+rRQrwpiZVVqUX58UWlOanFhxilOViUxHktsmqjhATSE0tSs1NTC1KLYLJM HJxSDYxubffu1TtdW8auw3151fXsH+vt/kewu3sq7dZ59HrGbM1LpVaqz1417CuziGmLSHrV 9sVrntafb2//PblcdPi7b6da5Ibvz4V9b0/SOKJzON6cQ1GMadnHK5lOPpVvKgU3qaq4Fsdf nxMXcsg8jyO2+PvqmvfH9VpTQ26ER069kPM+5NLVBgclluKMREMt5qLiRADZpJUNfQIAAA== Archived-At: Subject: Re: [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 01:30:31 -0000 --Apple-Mail=_3961EC25-55C4-4F55-87D4-ABBC0038EC4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, responses inline. > On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews > wrote: >=20 > This does not meet my requirements. There is zero need for any part of = the normal DNS resolution > process to know the IPV4ONLY.ARPA is special if IANA stopped signing = the zone. Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? = It explains why some parts of the DNS resolution process do need to = treat ipv4only.arpa as special, regardless of DNSSEC. > On Jun 13, 2018, at 19:19, Warren Kumari wrote: >=20 > I read that a few times, and even when squinting I cannot figure out = how that is supposed to work. Can someone enlighten me? I can see how a = signed ipv4only.arpa allows a validating DNS64 server to validate the = (well known!) v4 addresses, but the malicious AAAA RR detection bit = confuses me... I agree, there is no point in signing the A records for ipv4only.arpa = since they are well-known, and for the same reason there is no point in = checking it. So having A records signed or unsigned is irrelevant since = no one should be querying for these A records anyway. Similarly, since = the whole purpose of the AAAA records for ipv4only.arpa is to be = overridden by a DNS64 recursive resolver which is not owned by .arpa, = checking signatures will not validate anything useful. I agree with Mark's point that queries will fail when the client is = behind a validating resolver that has no special knowledge of = ipv4only.arpa. To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to = mention that ipv4only.arpa MUST NOT be signed. Thanks, David= --Apple-Mail=_3961EC25-55C4-4F55-87D4-ABBC0038EC4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi, responses inline.

On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews = <marka@isc.org> = wrote:

This does not meet my requirements. There is zero need for any part of = the normal DNS = resolution
process to know the IPV4ONLY.ARPA is special if IANA stopped signing the = zone.

Could you take a look at = draft-cheshire-sudn-ipv4only-dot-arpa please? It explains why some parts = of the DNS resolution process do need to treat ipv4only.arpa as special, = regardless of DNSSEC.

On Jun 13, 2018, at 19:19, Warren Kumari <warren@kumari.net> = wrote:

I = read that a few times, and even when squinting I cannot figure out = how that is supposed to work. Can someone enlighten me? I can see how a = signed ipv4only.arpa allows a validating DNS64 server to validate the = (well known!) v4 addresses, but the malicious AAAA RR detection bit = confuses me...

I agree, there is no point in signing the A = records for ipv4only.arpa since they are well-known, and for the same = reason there is no point in checking it. So having A records signed or = unsigned is irrelevant since no one should be querying for these A = records anyway. Similarly, since the whole purpose of the AAAA records = for ipv4only.arpa is to be overridden by a DNS64 recursive resolver = which is not owned by .arpa, checking signatures will not validate = anything useful.

I agree with Mark's = point that queries will fail when the client is behind a validating = resolver that has no special knowledge of ipv4only.arpa.

To resolve this, we'll = update draft-cheshire-sudn-ipv4only-dot-arpa to mention that = ipv4only.arpa MUST NOT be signed.

Thanks,
David
= --Apple-Mail=_3961EC25-55C4-4F55-87D4-ABBC0038EC4C-- From nobody Mon Jun 18 18:36:15 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 C711A130FDC for ; Mon, 18 Jun 2018 18:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HSaIXR4ixsR for ; Mon, 18 Jun 2018 18:36:02 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC86E130F9D for ; Mon, 18 Jun 2018 18:36:02 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id t5-v6so18610400ioa.8 for ; Mon, 18 Jun 2018 18:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BL7dz2uJoEIGnKNtzkAMGKNe3XwBGQEKXiJ3m15Z9BY=; b=ChHFyI26cbu0Or0MX4sEVd5zsoCWxI2SL5BffeMu8pVjniYMNOUzLTiqPkOaBD5zQt 7v57wexO7BsN5v+FoL4LR6AmHycTuM/dbe0B2g2lMm/ETYfZ6HTYrymox7FbNTAqWhVh k+xjI7Y8cUOVW1qflbKbrlRJh1LFh5Jszp4rKJF/IdpBgBfs/10qYVWQUFfAUxzGzehy apXcG+rLjPpA1BQRSaG7E1cobpMKoAxOTOabBqelBI/D7K0CHo7xjF8+b3gyzqGiN3pH l6NDQRHnhropyfDiJ/hKixCf7OtQ6sBguuucl/kdZiGd5GH3o5t9EA8dTrzK6V9KMHZH zVxQ== 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=BL7dz2uJoEIGnKNtzkAMGKNe3XwBGQEKXiJ3m15Z9BY=; b=gwylIwt39wZwQxLkz8/TYHN3EuzkhnTbXAQIBNygSebGwFgfO+YIsk/nqXA0EzV0il OQeH4UMbs3u2qXj4vkx//Q+e3i84ajumRmgbT/MyHJfMP73YSNl45N6+IFUC00IBy+Mw LhKovSHNSCIKzg1lvqdECQLK/XC5y+LwQy5DJQZoGbzFTyr8Ft5/z2jHO2rCTuzWHXCd 7gLh54haND3rQLBisGLuXGFY463v+a8lgfFawl+kxzMetRwvZvDN19tA9IsJOwCBskkB +gWSASwjeJSgPZ8lPfRFs7unDYsHfJoaCIpVVXKj8vYAp/zHReKsfjUo/JhnSVxM45n3 zmVQ== X-Gm-Message-State: APt69E3dghmd0z/yXi5JbWO+M2xA3kbLXDuq9aPrXSuc65mXSpAirMMB eGnYG8lgPknVcTOPySxJVhErDb0fW4u3gD6/SCCizQ== X-Google-Smtp-Source: ADUXVKICymgh4nL6Aqzl9GrAlpTWFedZBldgtua1ay3AiskvDlOayyIaI3q9UQkLrgZsQHWAJDcXA+1PLk/Y5S4TIVo= X-Received: by 2002:a6b:9156:: with SMTP id t83-v6mr12509779iod.32.1529372162097; Mon, 18 Jun 2018 18:36:02 -0700 (PDT) MIME-Version: 1.0 References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> In-Reply-To: From: Ted Lemon Date: Mon, 18 Jun 2018 21:35:51 -0400 Message-ID: To: David Schinazi Cc: IPv6 Operations , Mark Andrews , Michelle Cotton via RT , Stuart Cheshire , Warren Kumari , dnsop Content-Type: multipart/alternative; boundary="000000000000739aba056ef4b4f7" Archived-At: Subject: Re: [v6ops] [DNSOP] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 01:36:08 -0000 --000000000000739aba056ef4b4f7 Content-Type: text/plain; charset="UTF-8" You should steal the text from the dot home RFC. On Mon, Jun 18, 2018 at 9:30 PM David Schinazi wrote: > Hi, responses inline. > > On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews wrote: > >> >> This does not meet my requirements. There is zero need for any part of >> the normal DNS resolution > > process to know the IPV4ONLY.ARPA is special if IANA stopped signing the >> zone. > > > Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? It > explains why some parts of the DNS resolution process do need to treat > ipv4only.arpa as special, regardless of DNSSEC. > > On Jun 13, 2018, at 19:19, Warren Kumari wrote: > > > I read that a few times, and even when squinting I cannot figure out how > that is supposed to work. Can someone enlighten me? I can see how a signed > ipv4only.arpa allows a validating DNS64 server to validate the (well > known!) v4 addresses, but the malicious AAAA RR detection bit confuses me... > > > I agree, there is no point in signing the A records for ipv4only.arpa > since they are well-known, and for the same reason there is no point in > checking it. So having A records signed or unsigned is irrelevant since no > one should be querying for these A records anyway. Similarly, since the > whole purpose of the AAAA records for ipv4only.arpa is to be overridden by > a DNS64 recursive resolver which is not owned by .arpa, checking signatures > will not validate anything useful. > > I agree with Mark's point that queries will fail when the client is behind > a validating resolver that has no special knowledge of ipv4only.arpa. > > To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to > mention that ipv4only.arpa MUST NOT be signed. > > Thanks, > David > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000739aba056ef4b4f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You should steal the text from the dot home RFC.=C2= =A0

On Mon, Jun 18, 201= 8 at 9:30 PM David Schinazi <dsch= inazi@apple.com> wrote:
Hi, respons= es inline.

On Tue, Jun = 12, 2018 at 11:16 PM Mark Andrews <marka@isc.org> wrote:

This does not meet my requirements. There is zero need for any part of the = normal DNS resolution
process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zo= ne.

=
Could you take a look at draft-cheshire-sudn-ipv4only-d= ot-arpa please? It explains why some parts of the DNS resolution process do= need to treat ipv4only.arpa as special, regardless of DNSSEC.
<= /div>

On Jun 13, 201= 8, at 19:19, Warren Kumari <warren@kumari.net> wrote:

I read that a few times, and ev= en when squinting=C2=A0I cannot figure out how that is supposed to work. Ca= n someone enlighten me? I can see how a signed ipv4only.arpa allows a valid= ating DNS64 server to validate the (well known!) v4 addresses, but the mali= cious AAAA RR detection bit confuses me...

I agree, there is= no point in signing the A records for ipv4only.arpa since they are well-kn= own, and for the same reason there is no point in checking it. So having A = records signed or unsigned is irrelevant since no one should be querying fo= r these A records anyway. Similarly, since the whole purpose of the AAAA re= cords for ipv4only.arpa is to be overridden by a DNS64 recursive resolver w= hich is not owned by .arpa, checking signatures will not validate anything = useful.

I agree with Mark's point that queries= will fail when the client is behind a validating resolver that has no spec= ial knowledge of ipv4only.arpa.

To resolve this, w= e'll update=C2=A0draft-cheshire-sudn-ipv4only-dot-arpa to mention that = ipv4only.arpa MUST NOT be signed.

Than= ks,
David
______________________________________= _________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000739aba056ef4b4f7-- From nobody Mon Jun 18 19:16: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 53AA0131045; Mon, 18 Jun 2018 19:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fvckevYfKSq9; Mon, 18 Jun 2018 19:16:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E150131030; Mon, 18 Jun 2018 19:16:10 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6E0153AB03F; Tue, 19 Jun 2018 02:16:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 37809160079; Tue, 19 Jun 2018 02:16:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 20BC416008D; Tue, 19 Jun 2018 02:16:06 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qSlYQdjDoOxQ; Tue, 19 Jun 2018 02:16:06 +0000 (UTC) Received: from rock-73422.home.lan (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 94732160079; Tue, 19 Jun 2018 02:16:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Tue, 19 Jun 2018 12:16:01 +1000 Cc: David Schinazi , IPv6 Operations , Michelle Cotton via RT , Stuart Cheshire , Warren Kumari , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> To: Ted Lemon X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [DNSOP] [IANA #989438] ipv4only.arpa's delegation should be insecure. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 02:16:13 -0000 > On 19 Jun 2018, at 11:35 am, Ted Lemon wrote: >=20 > You should steal the text from the dot home RFC.=20 >=20 > On Mon, Jun 18, 2018 at 9:30 PM David Schinazi = wrote: > Hi, responses inline. >=20 >> On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews wrote: >>=20 >> This does not meet my requirements. There is zero need for any part = of the normal DNS resolution >> process to know the IPV4ONLY.ARPA is special if IANA stopped signing = the zone. >=20 > Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? = It explains why some parts of the DNS resolution process do need to = treat ipv4only.arpa as special, regardless of DNSSEC. >=20 >> On Jun 13, 2018, at 19:19, Warren Kumari wrote: >>=20 >> I read that a few times, and even when squinting I cannot figure out = how that is supposed to work. Can someone enlighten me? I can see how a = signed ipv4only.arpa allows a validating DNS64 server to validate the = (well known!) v4 addresses, but the malicious AAAA RR detection bit = confuses me... >=20 > I agree, there is no point in signing the A records for ipv4only.arpa = since they are well-known, and for the same reason there is no point in = checking it. So having A records signed or unsigned is irrelevant since = no one should be querying for these A records anyway. Similarly, since = the whole purpose of the AAAA records for ipv4only.arpa is to be = overridden by a DNS64 recursive resolver which is not owned by .arpa, = checking signatures will not validate anything useful. No. You expect DNS64 recursive server to query for them as part of the = synthesis process when they get a request from a device that is = attempting to configuring the CLAT service by asking for the AAAA = records for ipv4only.arpa. And to be pedantic one is overriding the = NODATA response as there are no AAAA records for ipv4only.arpa. > I agree with Mark's point that queries will fail when the client is = behind a validating resolver that has no special knowledge of = ipv4only.arpa. >=20 > To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to = mention that ipv4only.arpa MUST NOT be signed. >=20 > Thanks, > David > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 18 22: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 D569C128CF3 for ; Mon, 18 Jun 2018 22:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9itd1oXwXTG for ; Mon, 18 Jun 2018 22:41:12 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D95E124D68 for ; Mon, 18 Jun 2018 22:41:12 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 418xdy6yq4z2yfT; Tue, 19 Jun 2018 07:41:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id D3828C0052; Tue, 19 Jun 2018 07:41:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0399.000; Tue, 19 Jun 2018 07:41:10 +0200 From: To: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Thread-Index: AQHUByaHf7wxSfX1wkevfvtKjVzE26RnDzeA Date: Tue, 19 Jun 2018 05:41:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF472EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> In-Reply-To: <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 05:41:16 -0000 SGkgSm9yZGksIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKT1JESSBQQUxFVCBNQVJUSU5FWiBb bWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDE4 IGp1aW4gMjAxOCAxOTowNQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+IENj wqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTAzLnR4dA0KPiANCj4gSGkgTWVkLA0K PiANCj4gDQo+IA0KPiBUaGFua3MgYSBsb3QgZm9yIHlvdXIgaW5wdXRzLg0KPiANCj4gDQo+IA0K PiBJJ3ZlIGZldyBjb21tZW50czoNCj4gDQo+IDEpIFRoZSByZXF1aXJlbWVudHMgbGFuZ3VhZ2Ug aXMgdGhlIHNhbWUgYXMgaXQgd2FzIHVzZWQgaW4gUkZDNzA4NC4gV2UNCj4gYmVsaWV2ZSBpdCBt YWtlcyBhIGxvdCBvZiBzZW5zZSB0byBmb2xsb3cgdGhhdC4NCj4gDQoNCltNZWRdIE15IGNvbW1l bnQgd2FzIGFib3V0ICJVbmxpa2Ugb3RoZXIgSUVURiBkb2N1bWVudHMsIi4gQXMgeW91IG1lbnRp b25lZCwgdGhlIGNvcmUgdGV4dCBpcyBhbHNvIGluIDcwODQgd2hpY2ggaXMgYW4gSUVURiBkb2N1 bWVudCEgUGxlYXNlIGNvbnNpZGVyIGRlbGV0aW5nIHRoYXQgbWVudGlvbi4gDQoNCj4gDQo+IA0K PiAyKSBTb21lIG9mIHRoZSBjb21tZW50cyBhcmUgcmVsYXRlZCB0byB0aGUgdXNhZ2Ugb2YgZXhw cmVzc2lvbnMgc3VjaCBhcw0KPiBzZXJ2aWNlcyB2cyBzZXJ2ZXJzLCB0cmFuc2l0aW9uIHZzIHNl cnZpY2UgY29udGludWl0eSwgZXRjLiBUaGUgYXV0aG9ycw0KPiBjb25zaWRlciB0aGF0IGl0IGlz IGdvb2QgdG8gdXNlIHRob3NlIGludGVyY2hhbmdlYWJsZSB3b3JkaW5ncywgYmVjYXVzZSBmb3IN Cj4gZXhhbXBsZSwgaWYgd2UgZG9uJ3QgbWVudGlvbiB0cmFuc2l0aW9uLCBhIHJlYWRlciBtYXkg YmUgY29uZnVzZWQNCj4gdW5kZXJzdGFuZGluZyB0aGF0IHRoaXMgaXMgbm90IHJlZ2FyZGluZyB0 cmFuc2l0aW9uIGJ1dCBhIG5ldyBwcm9ibGVtDQo+ICJzZXJ2aWNlIGNvbnRpbnVpdHkiLiBBbnl3 YXksIHdlIHdpbGwgdGFrZSBhIGxvb2sgYWdhaW4gaW50byB0aGlzLCBhbmQgYWxzbw0KPiBzZWVr IGZvciBvdGhlciBjb21tZW50cyBmcm9tIHRoZSBXRy4NCj4gDQo+IA0KPiANCj4gMykgV2lsbCBj bGFyaWZ5IGFueXRoaW5nIHRoYXQgZG9lc24ndCBwYXJzZSBlYXNpbHkgZnJvbSB5b3VyIGlucHV0 cy4NCj4gDQo+IA0KPiANCj4gNCkgWW91J3JlIHJpZ2h0IHJlZ2FyZGluZyB0aGUgbnVtYmVyaW5n IG9mIG5ldyBHZW5lcmFsIGFuZCBMQU4gcmVxdWlyZW1lbnRzLA0KPiB0aGVyZSBpcyBubyByZWFz b24gbm93IHRvIGZvbGxvdyB0aGUgbnVtYmVyaW5nIG9mIFJGQzcwODQsIHdlIHdpbGwgc3RhcnQg ZnJvbQ0KPiAxLg0KPiANCj4gDQo+IA0KPiA1KSBXZSBiZWxpZXZlIHRoYXQgaXQgbWFrZXMgc2Vu c2UgdGhhdCBpbiB0aGUgREVGQVVMVCBjb25maWcsIGFjY29yZGluZyB3aXRoDQo+IHRoZSBkaXNj dXNzaW9uIGluIHRoZSBsaXN0LCB0cmFuc2l0aW9uIGlzIGRpc2FibGVkLCBzbyB3ZSBhdm9pZCBw b3NzaWJsZQ0KPiBjb25mbGljdHMsIHVubGVzcyB0aGUgSVNQIHR1cm5zIGl0IG9uIChmb2xsb3dp bmcgUkZDODAyNikgb3IgdGhlIHVzZXIgKGJ5DQo+IG1lYW5zIG9mIEdVSSBvciBDTEkpLg0KDQpb TWVkXSBSRkM4MDI2IGFzc3VtZXMgdGhhdCBjb3JyZXNwb25kaW5nIG9wdGlvbnMgYXJlIHJlcXVl c3RlZC4gSWYgYSBtZWNoYW5pc20gaXMgZGlzYWJsZWQsIEkgYXNzdW1lIHRoZSBjb3JyZXNwb25k aW5nIERIQ1Agb3B0aW9uIHdvbid0IGJlIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IHRvIHRoZSBz ZXJ2ZXIuIFRSQU5TLTEgaXMgcHJvYmxlbWF0aWMuDQoNCkkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFu ZCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IuDQoNCj4gDQo+IA0KPiANCj4gNikgVGhlIGNvZGUgY29u c2lkZXJhdGlvbnMgc2VjdGlvbiB3YXMgcmVxdWVzdGVkIGluIHY2b3BzIHRvIGJlIGtlZXAgYXMg cGFydA0KPiBvZiB0aGUgZG9jdW1lbnQsIG5vdCBhbiBhbm5leC4gV2UgYXJlIGhhcHB5IHRvIGNo YW5nZSB0aGF0IGFnYWluIGlmIHRoYXQncw0KPiB0aGUgV0cgZGVjaXNpb24uDQo+IA0KPiANCj4g DQo+IFdlIHdpbGwgd2FpdCBhIGZldyBleHRyYSBkYXlzIGZvciBhbnkgZnVydGhlciBpbnB1dHMg YmVmb3JlIHN1Ym1pdHRpbmcgYSBuZXcNCj4gdmVyc2lvbiAoYmVmb3JlIHRoZSBjdXQtb2ZmKS4N Cj4gDQo+IA0KPiANCj4gVGhhbmtzICENCj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEpv cmRpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDvu78tLS0tLU1lbnNhamUgb3JpZ2lu YWwtLS0tLQ0KPiANCj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBlbiBub21i cmUgZGUNCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IA0KPiBGZWNoYTogbHVu ZXMsIDE4IGRlIGp1bmlvIGRlIDIwMTgsIDE0OjI3DQo+IA0KPiBQYXJhOiBKT1JESSBQQUxFVCBN QVJUSU5FWiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NCj4g DQo+IENDOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NCj4gDQo+IEFzdW50bzog UmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRh YXMtMDMudHh0DQo+IA0KPiANCj4gDQo+ICAgICBIaSBKb3JkaSwNCj4gDQo+IA0KPiANCj4gICAg IEZXSVcsIHBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgdG8gdGhpcyBkcmFmdCBhdDoNCj4gDQo+ IA0KPiANCj4gICAgIHBkZjogaHR0cHM6Ly9naXRodWIuY29tL2JvdWNhZGFpci9JRVRGLURyYWZ0 cy1SZXZpZXdzL2Jsb2IvbWFzdGVyL2RyYWZ0LQ0KPiBpZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2 NGFhcy0wMy1yZXYlMjBNZWQucGRmDQo+IA0KPiAgICAgZG9jOiBodHRwczovL2dpdGh1Yi5jb20v Ym91Y2FkYWlyL0lFVEYtRHJhZnRzLVJldmlld3MvcmF3L21hc3Rlci9kcmFmdC0NCj4gaWV0Zi12 Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDMtcmV2JTIwTWVkLmRvYw0KPiANCj4gDQo+IA0KPiAg ICAgQ2hlZXJzLA0KPiANCj4gICAgIE1lZA0KPiANCj4gDQo+IA0KPiAgICAgPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gDQo+ICAgICA+IERlIDogdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpPUkRJIFBBTEVUDQo+IE1BUlRJTkVaDQo+ IA0KPiAgICAgPiBFbnZvecOpIDogc2FtZWRpIDE2IGp1aW4gMjAxOCAwODo1Nw0KPiANCj4gICAg ID4gw4AgOiB2Nm9wc0BpZXRmLm9yZw0KPiANCj4gICAgID4gT2JqZXQgOiBSZTogW3Y2b3BzXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0NCj4gMDMudHh0 DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gSGkgYWxsLA0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gQXMgaW5kaWNhdGVkIGEgY291cGxlIG9mIGRh eSBhZ28sIHdlIGhhdmUgdXBkYXRlZCB0aGlzIGRvY3VtZW50LCBzbw0KPiBpbnN0ZWFkDQo+IA0K PiAgICAgPiBvZiBhbiB1cGRhdGUgb2YgUkZDODAyNiBhbmQgYSBuZXcgb3B0aW9uIGNvZGUsIHdl IG9ubHkgbmVlZCB0byBhc2sgSUFOQQ0KPiB0bw0KPiANCj4gICAgID4gdXNlIGEgTkFUNjQgZXhp c3Rpbmcgb25lIGZvciB0aGUgUkZDODAyNiBwcmlvcml0eSB0YWJsZS4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gDQo+ICAgICA+IGlw djRhYXMvP2luY2x1ZGVfdGV4dD0xDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiBMZXQncyBrbm93IGFueSBjb21tZW50cyB5b3UgaGF2ZS4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFRoYW5rcyENCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFJlZ2FyZHMs DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gSm9yZGkNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4g ZW4gbm9tYnJlIGRlIDxpbnRlcm5ldC0NCj4gZHJhZnRzQGlldGYub3JnPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+IEZlY2hhOiBzw6FiYWRvLCAxNiBkZSBqdW5pbyBkZSAyMDE4LCA4OjQzDQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gUGFyYTogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiBDQzogPHY2b3BzQGlldGYub3JnPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+IEFzdW50bzogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3Bz LXRyYW5zaXRpb24taXB2NGFhcy0wMy50eHQNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cw0KPiANCj4gICAgID4gZGlyZWN0b3JpZXMuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4g ICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXRyBv ZiB0aGUgSUVURi4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+ICAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJlcXVpcmVtZW50cyBmb3IgSVB2 NiBDdXN0b21lciBFZGdlDQo+IFJvdXRlcnMgdG8NCj4gDQo+ICAgICA+IFN1cHBvcnQgSVB2NCBD b25uZWN0aXZpdHkgYXMtYS1TZXJ2aWNlDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogSm9yZGkgUGFsZXQgTWFydGluZXoNCj4gDQo+ICAgICA+ DQo+IA0KPiAgICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5zIE0uLUguIExp dQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE1hc2Fub2J1IEthd2FzaGltYQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICAJRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDMudHh0DQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIAlQYWdlcyAgICAgICAgICAgOiAyMA0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxOC0wNi0xNQ0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIEFic3Ry YWN0Og0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICAgICBUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyB0aGUgSVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkgcmVxdWlyZW1lbnRzDQo+IGZvcg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICAgICAgICBhbiBJUHY2IEN1c3RvbWVyIEVkZ2UgKENFKSBy b3V0ZXIsIGVpdGhlciBwcm92aWRlZCBieSB0aGUNCj4gc2VydmljZQ0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICAgICBwcm92aWRlciBvciB0aHJ1IHRoZSByZXRhaWwgbWFya2V0Lg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIFNw ZWNpZmljYWxseSwgdGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSAiQmFzaWMgUmVxdWlyZW1lbnRz IGZvcg0KPiBJUHY2DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIEN1c3RvbWVyIEVk Z2UgUm91dGVycyIgaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHByb3Zpc2lvbmluZyBvZg0KPiBJUHY2 DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIHRyYW5zaXRpb24gc2VydmljZXMgZm9y IHRoZSBzdXBwb3J0IG9mICJJUHY0IGFzLWEtU2VydmljZSINCj4gKElQdjRhYVMpDQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgICAgIGJ5IG1lYW5zIG9mIG5ldyB0cmFuc2l0aW9uIG1lY2hh bmlzbXMuICBUaGUgZG9jdW1lbnQgb25seSBjb3ZlcnMNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgICAgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgZm9yIGRlbGl2ZXJpbmcgSVB2NCBpbiBJ UHY2LW9ubHkgYWNjZXNzDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIG5ldHdvcmtz LCBjb21tb25seSBjYWxsZWQgIklQdjQgYXMtYS1TZXJ2aWNlIiAoSVB2NGFhUyksIGFzDQo+IHJl cXVpcmVkDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIGluIGEgd29ybGQgd2hlcmUg SVB2NCBhZGRyZXNzZXMgYXJlIG5vIGxvbmdlciBhdmFpbGFibGUsIHNvDQo+IGhvc3RzIGluDQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIHRoZSBjdXN0b21lciBMQU5zIHdpdGggSVB2 NC1vbmx5IG9yIElQdjYtb25seSBhcHBsaWNhdGlvbnMgb3INCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgICAgZGV2aWNlcywgcmVxdWlyaW5nIHRvIGNvbW11bmljYXRlIHdpdGggSVB2NC1v bmx5IHNlcnZpY2VzIGF0IHRoZQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICAgICBJbnRl cm5ldCwgYXJlIHN0aWxsIGFibGUgdG8gZG8gc28uDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLQ0KPiBpcHY0YWFzLw0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIFRoZXJlIGFyZSBhbHNvIGh0 bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlv bi1pcHY0YWFzLTAzDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLQ0KPiAN Cj4gICAgID4gaXB2NGFhcy0wMw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4gICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFh cy0wMw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gDQo+ICAgICA+IHN1Ym1p c3Npb24NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgIHY2b3BzQGlldGYub3JnDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+ICAgICA+ DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCj4gDQo+ICAgICA+IElQdjQgaXMgb3Zlcg0KPiANCj4gICAgID4gQXJlIHlv dSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IA0KPiAgICAgPiBodHRwOi8vd3d3LmNv bnN1bGludGVsLmVzDQo+IA0KPiAgICAgPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gDQo+ICAgICA+IGNvbmZpZGVudGlhbC4gVGhl IGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZQ0KPiBv ZiB0aGUNCj4gDQo+ICAgICA+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIg bm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZA0KPiBkaXNjbG9zdXJlLA0KPiANCj4gICAgID4gY29w eWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1h dGlvbiwgZXZlbg0KPiBpZg0KPiANCj4gICAgID4gcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUNCj4gDQo+ICAgICA+ IGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IGJlDQo+IGF3YXJlDQo+IA0KPiAgICAgPiB0aGF0IGFueSBkaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZg0KPiB0aGlz DQo+IA0KPiAgICAgPiBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBh dHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkNCj4gDQo+ICAgICA+IHByb2hpYml0ZWQsIHdpbGwg YmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvDQo+ IHRoZQ0KPiANCj4gICAgID4gb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNv bW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IA0KPiAgICAgPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gDQo+ICAgICA+ IHY2b3BzQGlldGYub3JnDQo+IA0KPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gDQo+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gDQo+ICAg ICB2Nm9wc0BpZXRmLm9yZw0KPiANCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJlIHlv dSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50ZWwu ZXMNCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50 aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1l eHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZg0KPiBw YXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0aGF0IGFueSBkaXNjbG9z dXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz DQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZp bGVzLCBpcyBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmlt aW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUNCj4gb3JpZ2luYWwgc2VuZGVy IHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gDQo+ IA0KDQo= From nobody Tue Jun 19 00:08: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 452B6130ED0 for ; Tue, 19 Jun 2018 00:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IKbdd5ZJcBvL for ; Tue, 19 Jun 2018 00:08:36 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A588312E039 for ; Tue, 19 Jun 2018 00:08:35 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-42-96.kabelnet.hu [79.121.42.96]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5J78JGo070473 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 19 Jun 2018 09:08:26 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-96.kabelnet.hu [79.121.42.96] claimed to be [192.168.1.114] To: v6ops@ietf.org References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> Date: Tue, 19 Jun 2018 09:08:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> Content-Type: multipart/alternative; boundary="------------54997D827633412301F0E893" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.96; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 07:08:42 -0000 This is a multi-part message in MIME format. --------------54997D827633412301F0E893 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Lee, Thank you very much for offering your help and participation. I have decided to write the draft and I invite you to be a co-author. Are there some other people, who would like to join us? I plan to put together a table with the information extracted from past e-mails on the list and send it to Lee (and possibly other participants) first, and send the Google docs URL to the list after we agreed on its initial content. Best regards, Gbor 6/18/2018 4:38 PM keltezssel, Lee Howard rta: > > Apparently I'm a week late on this thread. Sorry. > > I think an internet-draft in this case would be useful for reflecting > the current best knowledge about the technologies. Even if it takes > two years or more to publish, a draft is useful to collect and > summarize the detailed academic papers being published, and the > structure of writing the draft will help point out areas where further > research is needed. > > I'm also interested in supporting this work, up to and including > working with your students, providing my own test results, and/or > co-authoring. > > Lee > > > On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote: >> >> Im not sure it makes sense something that is not published in, lets >> say, maximum one year from now. >> >> Anyway, Im happy to help. >> >> By the way, I got some private questions about this The table that >> Ive posted yesterday, was developed about 3 years ago, and Ive not >> updated it since them. Actually from emails exchanged today, I >> discovered a couple of mistakes and also things that can be improved, >> so if needed I can update it as well. >> >> >> Regards, >> >> Jordi >> >> *De: *v6ops en nombre de Lencse Gbor >> >> *Fecha: *viernes, 15 de junio de 2018, 14:25 >> *Para: *Fred Baker >> *CC: * >> *Asunto: *[v6ops] Pros and Cons of IPv6 Transition Technologies for >> IPv4aaS -- Re: no need to update RFC8026 in >> draft-ietf-v6ops-transition-ipv4aas >> >> Dear Fred, >> >> Thank you very much for your invitation. I am willing to accept it, >> but I would like to clarify your expectations before saying 'yes'. >> >> I have several questions. >> >> 1. Depth of the analysis >> >> - Basic level: well-known advantages and disadvantages, similarly as >> people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. >> - Advanced level: basic level + security analysis using the >> methodology defined in [1] + performance analysis according to RFC 8219. >> >> What depth do you recommend? >> >> 2. Method for getting the results and their publication >> >> As for the information for the basic level, I would prepare a google >> docs table, fill in the information I have and send the link to the >> v6ops list asking contributions. >> After commenting and discussing, I would compile it to an I-D. >> >> Do you think that v6ops WG would finally agree to publish it as an RFC? >> >> As for the information for the advanced level, I would work together >> with my students and PhD students, and publish our results first in >> academic papers and then include their most important lessons into >> the I-D. >> >> What do you think of it? >> >> 3. Timeline >> >> I think that I could put together the first table in a few weeks. The >> contribution of the v6ops list members and the discussion could be >> done in a few months and then I could compile the results into an I-D >> in a few weeks. Perhaps, it could be presented at IETF 103. >> >> The further parts would require much more time and results could be >> included gradually in 1-2 years. >> >> 4. Scope >> >> The smallest natural scope includes the technologies for IPv4AAS, >> that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6. >> >> IPv6 transition technologies for other carefully selected scenarios >> might also be included. E.g. I have significant amount of results in >> benchmarking DNS64 servers, having a testing tool [2], a well defined >> methodology [3] and ready to use results concerning the DNS64 >> performance of BIND, PowerDNS and Unbound [4]. >> One of my PhD students is currently benchmarking some sateless NAT64 >> implementations according the the dual DUT setup of RFC 8219 using an >> RFC 2544 compatible Tester. Another PhD student is currently working >> on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able >> to perform single DUT setup NAT64 benchmarking tests. >> >> Thus, the scope can be widened, if you would like to. >> >> What do you think about my recommendations? >> >> Best regards, >> >> Gbor >> >> References: >> >> [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification >> of potential security issues of different IPv6 transition >> technologies: Threat analysis of DNS64 and stateful NAT64", >> /Computers & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, >> August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 >> >> [2] G. Lencse, D. Bakai, "Design and implementation of a test program >> for benchmarking DNS64 servers", /IEICE Transactions on >> Communications/, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: >> 10.1587/transcom.2016EBN0007 >> >> [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking >> Methodology for DNS64 Servers", /Computer Communications/ (Elsevier), >> vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: >> 10.1016/j.comcom.2017.06.004 >> >> [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 >> Implementations: Theory and Practice", /Computer Communications/ >> (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: >> 10.1016/j.comcom.2018.05.005 >> >> 6/14/2018 10:42 PM keltezssel, Fred Baker rta: >> >> On Jun 14, 2018, at 1:15 PM, Lencse Gbor wrote: >> >> I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.) >> >> It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder. >> >> We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost. >> >> So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T. >> >> And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic). >> >> If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks... >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged >> or confidential. The information is intended to be for the exclusive >> use of the individual(s) named above and further non-explicilty >> authorized disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, is >> strictly prohibited and will be considered a criminal offense. If you >> are not the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited, will be >> considered a criminal offense, so you must reply to the original >> sender to inform about this communication and delete it. >> >> >> >> _______________________________________________ >> 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 --------------54997D827633412301F0E893 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear Lee,

Thank you very much for offering your help and participation. I have decided to write the draft and I invite you to be a co-author.

Are there some other people, who would like to join us?

I plan to put together a table with the information extracted from past e-mails on the list and send it to Lee (and possibly other participants) first, and send the Google docs URL to the list after we agreed on its initial content.

Best regards,

Gbor


6/18/2018 4:38 PM keltezssel, Lee Howard rta:

Apparently I'm a week late on this thread. Sorry.

I think an internet-draft in this case would be useful for reflecting the current best knowledge about the technologies. Even if it takes two years or more to publish, a draft is useful to collect and summarize the detailed academic papers being published, and the structure of writing the draft will help point out areas where further research is needed.

I'm also interested in supporting this work, up to and including working with your students, providing my own test results, and/or co-authoring.

Lee


On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote:

Im not sure it makes sense something that is not published in, lets say, maximum one year from now.

Anyway, Im happy to help.

By the way, I got some private questions about this The table that Ive posted yesterday, was developed about 3 years ago, and Ive not updated it since them. Actually from emails exchanged today, I discovered a couple of mistakes and also things that can be improved, so if needed I can update it as well.


Regards,

Jordi

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse Gbor <lencse@hit.bme.hu>
Fecha: viernes, 15 de junio de 2018, 14:25
Para: Fred Baker <fredbaker.ietf@gmail.com>
CC: <v6ops@ietf.org>
Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas

Dear Fred,

Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'.

I have several questions.

1. Depth of the analysis

- Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
- Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219.

What depth do you recommend?

2. Method for getting the results and their publication

As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions.
After commenting and discussing, I would compile it to an I-D.

Do you think that v6ops WG would finally agree to publish it as an RFC?

As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D.

What do you think of it?

3. Timeline

I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103.

The further parts would require much more time and results could be included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.

IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4].
One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests.

Thus, the scope can be widened, if you would like to.

What do you think about my recommendations?

Best regards,

Gbor

References:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007

[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

6/14/2018 10:42 PM keltezssel, Fred Baker rta:

On Jun 14, 2018, at 1:15 PM, Lencse Gbor <lencse@hit.bme.hu> wrote:
I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.)
It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder.
We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost.
So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T.
And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic).
If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks...


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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.



_______________________________________________
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

--------------54997D827633412301F0E893-- From nobody Tue Jun 19 00:28: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 12071130DDE for ; Tue, 19 Jun 2018 00:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wV_6r09t6-L for ; Tue, 19 Jun 2018 00:28:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5AD130DC8 for ; Tue, 19 Jun 2018 00:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529393325; x=1529998125; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=JE15wW1045/NcUiu/NfCH+Glkr7LWj9am0 r8gGZUK3M=; b=RGF3KkXSBfCyJ+fUdvJ8JDSGIlcxitcLtD30SCxR8fuFQALmS9 R9YncbUqbDT2186K2z6eazkXItmvcppBB/BUXEKryUdr2sGwE5zcGpCicax6EoQd IKvU6UiWMfp9hRXblNMyGDSzNJsRmkCAYLHUY9+BDZz8hSeZ8yDrKBUq8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 19 Jun 2018 09:28:45 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 19 Jun 2018 09:28:44 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005791856.msg for ; Tue, 19 Jun 2018 09:28:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:18f1:8adf:2937:1bf8 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 19 Jun 2018 09:28:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1708280bf9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Tue, 19 Jun 2018 09:28:42 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: Thread-Topic: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> In-Reply-To: <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3612245322_42871790" Archived-At: Subject: Re: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 07:28:52 -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_3612245322_42871790 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Lenser, =20 Yeah, I will be happy to join as well. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: martes, 19 de junio de 2018, 9:09 Para: Asunto: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Techn= ologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-tr= ansition-ipv4aas =20 Dear Lee, Thank you very much for offering your help and participation. I have decide= d to write the draft and I invite you to be a co-author. Are there some other people, who would like to join us? I plan to put together a table with the information extracted from past e-m= ails on the list and send it to Lee (and possibly other participants) first= , and send the Google docs URL to the list after we agreed on its initial c= ontent. Best regards, G=C3=A1bor 6/18/2018 4:38 PM keltez=C3=A9ssel, Lee Howard =C3=ADrta: Apparently I'm a week late on this thread. Sorry. I think an internet-draft in this case would be useful for reflecting the c= urrent best knowledge about the technologies. Even if it takes two years or= more to publish, a draft is useful to collect and summarize the detailed = academic papers being published, and the structure of writing the draft wil= l help point out areas where further research is needed. I'm also interested in supporting this work, up to and including working wi= th your students, providing my own test results, and/or co-authoring. Lee =20 On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote: I=E2=80=99m not sure it makes sense something that is not published in, let= =E2=80=99s say, maximum one year from now. =20 Anyway, I=E2=80=99m happy to help. =20 By the way, I got some private questions about this =E2=80=A6 The table tha= t I=E2=80=99ve posted yesterday, was developed about 3 years ago, and I=E2= =80=99ve not updated it since them. Actually from emails exchanged today, I= discovered a couple of mistakes and also things that can be improved, so i= f needed I can update it as well. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: viernes, 15 de junio de 2018, 14:25 Para: Fred Baker CC: Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -= - Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas =20 Dear Fred, Thank you very much for your invitation. I am willing to accept it, but I w= ould like to clarify your expectations before saying 'yes'. I have several questions. 1. Depth of the analysis - Basic level: well-known advantages and disadvantages, similarly as people= wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. - Advanced level: basic level + security analysis using the methodology def= ined in [1] + performance analysis according to RFC 8219. What depth do you recommend? 2. Method for getting the results and their publication As for the information for the basic level, I would prepare a google docs t= able, fill in the information I have and send the link to the v6ops list as= king contributions. After commenting and discussing, I would compile it to an I-D.=20 Do you think that v6ops WG would finally agree to publish it as an RFC? As for the information for the advanced level, I would work together with m= y students and PhD students, and publish our results first in academic pape= rs and then include their most important lessons into the I-D. What do you think of it? 3. Timeline I think that I could put together the first table in a few weeks. The contr= ibution of the v6ops list members and the discussion could be done in a few= months and then I could compile the results into an I-D in a few weeks. Pe= rhaps, it could be presented at IETF 103. The further parts would require much more time and results could be include= d gradually in 1-2 years. 4. Scope The smallest natural scope includes the technologies for IPv4AAS, that is: = 464XLAT, DS-Lite, MAP-T/E and lw4o6. IPv6 transition technologies for other carefully selected scenarios might a= lso be included. E.g. I have significant amount of results in benchmarking = DNS64 servers, having a testing tool [2], a well defined methodology [3] an= d ready to use results concerning the DNS64 performance of BIND, PowerDNS a= nd Unbound [4].=20 One of my PhD students is currently benchmarking some sateless NAT64 implem= entations according the the dual DUT setup of RFC 8219 using an RFC 2544 co= mpatible Tester. Another PhD student is currently working on a RFC 8219 com= pliant NAT64 tester program (using DPDK) to be able to perform single DUT s= etup NAT64 benchmarking tests.=20 Thus, the scope can be widened, if you would like to. What do you think about my recommendations? Best regards, G=C3=A1bor References: [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of po= tential security issues of different IPv6 transition technologies: Threat a= nalysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol.= 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 [2] G. Lencse, D. Bakai, "Design and implementation of a test program for b= enchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100= -B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007 [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology = for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp= . 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004 [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theo= ry and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. = 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker =C3=ADrta: =20 On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor wrote: I have an idea: perhaps you could add a section about the pros and cons of = each transition technology covered by the draft. (It could be helpful for t= he network operators when selecting the technology matching their need the = best. However, I am not sure whether it is in the scope of this draft.) It would be incredibly useful. That said, it often involves value judgement= s, which are essentially in the eye of the beholder. =20 We have had a recent thread regarding 464xlat and MAP-T. If I can say this = without actually putting words into Lorenzo's mouth, his issues with transl= ation in general are probably summarized in RFC 2993, and I would agree wit= h him. The distinction between 464xlat and MAP-T you'll have to find in his= emails; they are both services an ISP might deploy, and while they use the= same tool (translation) they are not the same service. It seems to be gene= rally agreed that MAP-T is more expensive to deploy than 464xlat; the quest= ion is what the extra expense buys, and whether someone agrees that the res= ult is worth the cost. =20 So in your proposed section, I would have to ask Jordi to not only say "MAP= -T costs more to deploy than 464xlat", but gives the argument that might le= ad someone to choose MAP-T. =20 And then we get to the large variety of other technologies, some of which p= resume an IPv4 core network and some an IPv6 core network (and none of whic= h assume an MPLS core network carrying both kinds of traffic). =20 If you would like to write such a document, please be my guest, by all mean= s. But I'm not going to expect Jordi to do all that in the coming two weeks= ... _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3612245322_42871790 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Lenser,

 

Yeah, I will be happy to join as well.


Reg= ards,

Jordi

 

 

 

De: = v6ops <v6ops-bounces@ietf.org> en nombre de Lencse G=C3=A1bor <len= cse@hit.bme.hu>
Fecha: martes, 19 de junio de 2018, 9:09
Para: <v6ops@ietf.org>
Asunto: [v6ops] "BoF"= for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -= - Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas=

 

Dear Lee,=

Thank you very much for offering your help and participation. I hav= e decided to write the draft and I invite you to be a co-author.

Are= there some other people, who would like to join us?

I plan to put t= ogether a table with the information extracted from past e-mails on the lis= t and send it to Lee (and possibly other participants) first, and send the = Google docs URL to the list after we agreed on its initial content.

= Best regards,

G=C3=A1bor

6/18/2018 4:38 PM keltez=C3=A9ssel, Lee H= oward =C3=ADrta:

Apparently I'm a week = late on this thread. Sorry.

I= think an internet-draft in this case would be useful for reflecting the cu= rrent best knowledge about the technologies. Even if it takes two years or = more to publish, a draft is useful to collect  and summarize the detai= led academic papers being published, and the structure of writing the draft= will help point out areas where further research is needed.

=

I'm also interested in supporting this work= , up to and including working with your students,  providing my own te= st results, and/or co-authoring.

Lee

 

On= 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote:

I=E2=80=99m not sure it makes sense something that is not publish= ed in, let=E2=80=99s say, maximum one year from now.

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

Anyway, I=E2=80=99m happy to help.

 

By the way, I got some private questions about t= his =E2=80=A6 The table that I=E2=80=99ve posted yesterday, was developed a= bout 3 years ago, and I=E2=80=99ve not updated it since them. Actually from= emails exchanged today, I discovered a couple of mistakes and also things = that can be improved, so if needed I can update it as well.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> e= n nombre de Lencse G=C3=A1bor <lenc= se@hit.bme.hu>
Fecha: viernes, 15 de junio de 2018, 14:25<= br>Para: Fred Baker <= fredbaker.ietf@gmail.com>
CC: <v6ops@ietf.org>
Asunto: [v6ops] Pros and Cons of= IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 = in draft-ietf-v6ops-transition-ipv4aas

 

Dear Fred,

Thank you very much for= your invitation. I am willing to accept it, but I would like to clarify yo= ur expectations before saying 'yes'.

I have several questions.
1. Depth of the analysis

- Basic level: well-known advantages and = disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but als= o about DS-Lite and lw4o6.
- Advanced level: basic level + security anal= ysis using the methodology defined in [1] + performance analysis according = to RFC 8219.

What depth do you recommend?

2. Method for getti= ng the results and their publication

As for the information for the = basic level, I would prepare a google docs table, fill in the information I= have and send the link to the v6ops list asking contributions.
After co= mmenting and discussing, I would compile it to an I-D.

Do you think= that v6ops WG would finally agree to publish it as an RFC?

As for t= he information for the advanced level, I would work together with my studen= ts and PhD students, and publish our results first in academic papers and t= hen include their most important lessons into the I-D.

What do you t= hink of it?

3. Timeline

I think that I could put together the= first table in a few weeks. The contribution of the v6ops list members and= the discussion could be done in a few months and then I could compile the = results into an I-D in a few weeks. Perhaps, it could be presented at IETF = 103.

The further parts would require much more time and results coul= d be included gradually in 1-2 years.

4. Scope

The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-L= ite, MAP-T/E and lw4o6.

IPv6 transition technologies for other caref= ully selected scenarios might also be included. E.g. I have significant amo= unt of results in benchmarking DNS64 servers, having a testing tool [2], a = well defined methodology [3] and ready to use results concerning the DNS64 = performance of BIND, PowerDNS and Unbound [4].
One of my PhD students i= s currently benchmarking some sateless NAT64 implementations according the = the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another= PhD student is currently working on a RFC 8219 compliant NAT64 tester prog= ram (using DPDK) to be able to perform single DUT setup NAT64 benchmarking = tests.

Thus, the scope can be widened, if you would like to.
What do you think about my recommendations?

Best regards,

G= =C3=A1bor

References:

[1] G. Lencse and Y. Kadobayashi, "= ;Methodology for the identification of potential security issues of differe= nt IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT6= 4", Computers & Security (Elsevier), vol. 77, no. 1, pp. 39= 7-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] G. Lencse= , D. Bakai, "Design and implementation of a test program for benchmark= ing DNS64 servers", IEICE Transactions on Communications, vol. = E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007
[3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Me= thodology for DNS64 Servers", Computer Communications (Elsevier= ), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2= 017.06.004

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS6= 4 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j= .comcom.2018.05.005


6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker = =C3=ADrta:

 
On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1b= or <lencse@hit.bme.hu> wrote= :
I have an idea: perhaps you could add a=
 section about the pros and cons of each transition technology covered by t=
he draft. (It could be helpful for the network operators when selecting the=
 technology matching their need the best. However, I am not sure whether it=
 is in the scope of this draft.)
It would be incredibly useful. That said, it often inv=
olves value judgements, which are essentially in the eye of the beholder.
 
We have had a recent thread regarding 464xla= t and MAP-T. If I can say this without actually putting words into Lorenzo'= s mouth, his issues with translation in general are probably summarized in = RFC 2993, and I would agree with him. The distinction between 464xlat and M= AP-T you'll have to find in his emails; they are both services an ISP might= deploy, and while they use the same tool (translation) they are not the sa= me service. It seems to be generally agreed that MAP-T is more expensive to= deploy than 464xlat; the question is what the extra expense buys, and whet= her someone agrees that the result is worth the cost.
 
So in your proposed section, I would have to ask Jordi to not on=
ly say "MAP-T costs more to deploy than 464xlat", but gives the a=
rgument that might lead someone to choose MAP-T.
 
And then we get to the large variety of other technologies, some of which presume a=
n IPv4 core network and some an IPv6 core network (and none of which assume=
 an MPLS core network carrying both kinds of traffic).
 
If you would like to write such a document, please be my guest,=
 by all means. But I'm not going to expect Jordi to do all that in the comi=
ng two weeks...


_______________________________________________ v6o= ps mailing list v6ops@ietf.org https://www.ietf.org/mail= man/listinfo/v6ops


**********************************************
IPv4 is = over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This el= ectronic message contains information which may be privileged or confidenti= al. The information is intended to be for the exclusive use of the individu= al(s) named above and further non-explicilty authorized disclosure, copying= , distribution or use of the contents of this information, even if partiall= y, including attached files, is strictly prohibited and will be considered = a criminal offense. If you are not the intended recipient be aware that any= disclosure, copying, distribution or use of the contents of this informati= on, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original send= er to inform about this communication and delete it.




_____________________________=
__________________
v6ops =
mailing list
v6ops@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/v6ops
<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>



____________________________________=
___________
v6ops mailing=
 list
v6ops@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/v6ops


_____________________________= __________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/m= ailman/listinfo/v6ops


****************************= ******************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3612245322_42871790-- From nobody Tue Jun 19 01:29:32 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 CFF3B1310AF for ; Tue, 19 Jun 2018 01:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 33rbSxhKIzSl for ; Tue, 19 Jun 2018 01:29:28 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8576130E61 for ; Tue, 19 Jun 2018 01:29:27 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id l6-v6so15974710iti.2 for ; Tue, 19 Jun 2018 01:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Sgagf6x79tkG8jOyGUpp+aRFUK3ciTh/N/upefpnqcU=; b=SNSdVChPmDVzu7lOAJHl4c+ySDSvAh0qV6kUYRvk/60PWV8bqPPvjVleSRDg3XCOhp nRCGn5/2Wuatz2WC/518Cvly1o6s+a49Ap1sB9buwe2D2nBsZLYOMdMjKwM7ExvLS//5 UEmg7Frd1w+elj2PcKm0iZPQ5vb2xJfN8W1MRMeZ2W8md3c7SIZ8bKTrYyvqwQjTbZKZ 61ZdzheRR3++YbiLIvoVRnCMzh0dpsaxsHWqlt5Y629M/ITe/c30y6vrOsMISw5stqkV iH9+M++sHnQ8RDqf22S+pzMDT/LU+mSEfL0A8LYqO50Ke50/4kkDm3eSbzREJPSUoZ74 zdqQ== 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:content-transfer-encoding; bh=Sgagf6x79tkG8jOyGUpp+aRFUK3ciTh/N/upefpnqcU=; b=R69FJ527OiuPV6oRN12e/L9IvQnEKrCUKAO+P981/V1fvigriOZYa55gkfj43X584j UxIfgcpCbO3JU7waz6ZXZ+oKBRfWH2c8iX0wX6YuTQGfi1EYmhInWj91rfsdr+jnaUz9 euMAZdfA5QvtMH/voLPccXyXX3HUCn2XstGEjHaFUYf5erWhy19JBo45xPxr/4z5+5C/ O2KkE2mkC3JTuk0T7AEN1SptPL0nkAnMUHtt/McEN7XnkUHtKzgxucGsLLLxdozlPZY/ bf0NHFMXUEz2oTCdEks8bZ9Fsw4hoBHb+Gq07+oYKcI6B5hD8HgqPtpv4HU2M4mj7jL3 Br+A== X-Gm-Message-State: APt69E01g1u92e/ZzSpiinR6L/IBtxDJUyhTw1dQTat+BuAtPk+CTYeK 3qqV1q7F/DMqiqblaR0lg4dtmh5r X-Google-Smtp-Source: ADUXVKKszTMST3Ku8++IO+M64HKWr1Ub7pGhlQtDajLcpQC79X9huetjP6rIx398bCaktAbYgg4zTg== X-Received: by 2002:a24:3c8:: with SMTP id e191-v6mr13079149ite.70.1529396966547; Tue, 19 Jun 2018 01:29:26 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id c24-v6sm5160909itd.39.2018.06.19.01.29.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 01:29:25 -0700 (PDT) Received: by mail-io0-f179.google.com with SMTP id t6-v6so19283027iob.10 for ; Tue, 19 Jun 2018 01:29:25 -0700 (PDT) X-Received: by 2002:a6b:1884:: with SMTP id 126-v6mr11941402ioy.183.1529396965261; Tue, 19 Jun 2018 01:29:25 -0700 (PDT) MIME-Version: 1.0 References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> In-Reply-To: <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> From: Richard Patterson Date: Tue, 19 Jun 2018 09:29:14 +0100 X-Gmail-Original-Message-ID: Message-ID: To: lencse@hit.bme.hu Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 08:29:31 -0000 Hi Lencse, I'd be happy to help also. -Richard On Tue, 19 Jun 2018 at 08:09, Lencse G=C3=A1bor wrote: > > Dear Lee, > > Thank you very much for offering your help and participation. I have deci= ded to write the draft and I invite you to be a co-author. > > Are there some other people, who would like to join us? > > I plan to put together a table with the information extracted from past e= -mails on the list and send it to Lee (and possibly other participants) fir= st, and send the Google docs URL to the list after we agreed on its initial= content. > > Best regards, > > G=C3=A1bor > > > 6/18/2018 4:38 PM keltez=C3=A9ssel, Lee Howard =C3=ADrta: > > Apparently I'm a week late on this thread. Sorry. > > I think an internet-draft in this case would be useful for reflecting the= current best knowledge about the technologies. Even if it takes two years = or more to publish, a draft is useful to collect and summarize the detaile= d academic papers being published, and the structure of writing the draft w= ill help point out areas where further research is needed. > > I'm also interested in supporting this work, up to and including working = with your students, providing my own test results, and/or co-authoring. > > Lee > > > On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote: > > I=E2=80=99m not sure it makes sense something that is not published in, l= et=E2=80=99s say, maximum one year from now. > > > > Anyway, I=E2=80=99m happy to help. > > > > By the way, I got some private questions about this =E2=80=A6 The table t= hat I=E2=80=99ve posted yesterday, was developed about 3 years ago, and I= =E2=80=99ve not updated it since them. Actually from emails exchanged today= , I discovered a couple of mistakes and also things that can be improved, s= o if needed I can update it as well. > > > Regards, > > Jordi > > > > > > > > De: v6ops en nombre de Lencse G=C3=A1bor > Fecha: viernes, 15 de junio de 2018, 14:25 > Para: Fred Baker > CC: > Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS= -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas > > > > Dear Fred, > > Thank you very much for your invitation. I am willing to accept it, but I= would like to clarify your expectations before saying 'yes'. > > I have several questions. > > 1. Depth of the analysis > > - Basic level: well-known advantages and disadvantages, similarly as peop= le wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. > - Advanced level: basic level + security analysis using the methodology d= efined in [1] + performance analysis according to RFC 8219. > > What depth do you recommend? > > 2. Method for getting the results and their publication > > As for the information for the basic level, I would prepare a google docs= table, fill in the information I have and send the link to the v6ops list = asking contributions. > After commenting and discussing, I would compile it to an I-D. > > Do you think that v6ops WG would finally agree to publish it as an RFC? > > As for the information for the advanced level, I would work together with= my students and PhD students, and publish our results first in academic pa= pers and then include their most important lessons into the I-D. > > What do you think of it? > > 3. Timeline > > I think that I could put together the first table in a few weeks. The con= tribution of the v6ops list members and the discussion could be done in a f= ew months and then I could compile the results into an I-D in a few weeks. = Perhaps, it could be presented at IETF 103. > > The further parts would require much more time and results could be inclu= ded gradually in 1-2 years. > > 4. Scope > > The smallest natural scope includes the technologies for IPv4AAS, that is= : 464XLAT, DS-Lite, MAP-T/E and lw4o6. > > IPv6 transition technologies for other carefully selected scenarios might= also be included. E.g. I have significant amount of results in benchmarkin= g DNS64 servers, having a testing tool [2], a well defined methodology [3] = and ready to use results concerning the DNS64 performance of BIND, PowerDNS= and Unbound [4]. > One of my PhD students is currently benchmarking some sateless NAT64 impl= ementations according the the dual DUT setup of RFC 8219 using an RFC 2544 = compatible Tester. Another PhD student is currently working on a RFC 8219 c= ompliant NAT64 tester program (using DPDK) to be able to perform single DUT= setup NAT64 benchmarking tests. > > Thus, the scope can be widened, if you would like to. > > What do you think about my recommendations? > > Best regards, > > G=C3=A1bor > > References: > > [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of = potential security issues of different IPv6 transition technologies: Threat= analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vo= l. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 > > [2] G. Lencse, D. Bakai, "Design and implementation of a test program for= benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E1= 00-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007 > > [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodolog= y for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, = pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004 > > [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Th= eory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp= . 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 > > 6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker =C3=ADrta: > > > > On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor wrote: > > I have an idea: perhaps you could add a section about the pros and cons o= f each transition technology covered by the draft. (It could be helpful for= the network operators when selecting the technology matching their need th= e best. However, I am not sure whether it is in the scope of this draft.) > > It would be incredibly useful. That said, it often involves value judgeme= nts, which are essentially in the eye of the beholder. > > > > We have had a recent thread regarding 464xlat and MAP-T. If I can say thi= s without actually putting words into Lorenzo's mouth, his issues with tran= slation in general are probably summarized in RFC 2993, and I would agree w= ith him. The distinction between 464xlat and MAP-T you'll have to find in h= is emails; they are both services an ISP might deploy, and while they use t= he same tool (translation) they are not the same service. It seems to be ge= nerally agreed that MAP-T is more expensive to deploy than 464xlat; the que= stion is what the extra expense buys, and whether someone agrees that the r= esult is worth the cost. > > > > So in your proposed section, I would have to ask Jordi to not only say "M= AP-T costs more to deploy than 464xlat", but gives the argument that might = lead someone to choose MAP-T. > > > > And then we get to the large variety of other technologies, some of which= presume an IPv4 core network and some an IPv6 core network (and none of wh= ich assume an MPLS core network carrying both kinds of traffic). > > > > If you would like to write such a document, please be my guest, by all me= ans. But I'm not going to expect Jordi to do all that in the coming two wee= ks... > > > _______________________________________________ v6ops mailing list v6ops@= ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jun 19 02:55: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 7C2421310D7 for ; Tue, 19 Jun 2018 02:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 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, T_HTML_ATTACH=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6EuTZrk4jSu for ; Tue, 19 Jun 2018 02:55:23 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::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 1D114130DC5 for ; Tue, 19 Jun 2018 02:55:23 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id w17-v6so10675653pll.9 for ; Tue, 19 Jun 2018 02:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:mime-version:subject:message-id:date:to; bh=fsjMXzjKFNEQmh8D6+QdkmGoTfAi6Nt2WOe9C/sqxZs=; b=F5doyMw2hF54esA7hpjMw15qmEYHlVDkJPt2hb9MpQN3Gqi+Aw6uPP96wMyP04W0dj cz/8uvbRBvmo5Wok/fE4KFJ+EZrhgXFy7YB74v9ciC5118XFqd9AHYkiCm/VBJ+1/rG0 dWqxYL7eObERE1LAqMXVKmut1/vgjfVvIEucoIZ2SU94VS7YAwalbramCVXOCZxTWEYg rRmWN5kwneSugVSc8pAv6jKWWfazQIFHWkZFGXfYS0OJNKNIelDirq5J72LUM5vylnM3 iir6fFv/54PhbyoVIo/UupektanpQWHhpOEMSS0Svw2nmqE00GcWc3V6lkjg7znCJhBP T1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:message-id :date:to; bh=fsjMXzjKFNEQmh8D6+QdkmGoTfAi6Nt2WOe9C/sqxZs=; b=OBBZ2Oo2kpT9tUNJ/PyvOj/R922mD8xuWyodo9DuvFoqS3fWc/3sRcg2TvKa3nyAqV lfaq49uP+5k48AmTI/otrNFrRj5wYMz1xX4zdQj21IqlsygMApMhAUKNLLNP+UxN06g3 8YckBsP6iPpA1T3U/xIiwkuEuHvfI4uozDJq1fp9l8kzpwQZM75KBwW04APSZvRI0JY3 89BDNu2YZ4U/0pnQH6/RZPwkRrIsLzdxs57NpIXBMKAcaQulKX7vY7GHKST/CEtHhcOZ TWliq13UCRswllBLCdbRvtqDGC0xOo50tKBtahMU0ZVDcC6tB9QYuXB1xAgMLnHT4ggF KtRA== X-Gm-Message-State: APt69E2VhK1t99h93Wog8Nvf5dLGFRKSUkUzyCAWzQ4EtzgEz/kknlN8 gOE+wLqF5fGdwZMtkM6uj/SLat3U X-Google-Smtp-Source: ADUXVKIhSb8jYIyU2vR9u7mbIuwqVDlIZ3O3bnqlTDcfr1eFDuxZtpHB2wOAXok6T+Q00cGFFrYFEQ== X-Received: by 2002:a17:902:bc4a:: with SMTP id t10-v6mr18000822plz.133.1529402122599; Tue, 19 Jun 2018 02:55:22 -0700 (PDT) Received: from [172.17.2.22] (125-227-167-218.HINET-IP.hinet.net. [125.227.167.218]) by smtp.gmail.com with ESMTPSA id v27-v6sm34296772pfi.23.2018.06.19.02.55.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 02:55:21 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_E70DCE30-8F42-46E5-AA0C-24149459B829"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: V6ops Chairs Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <82300162-DBC3-437A-8822-84C94B8C7722@gmail.com> Date: Tue, 19 Jun 2018 17:55:19 +0800 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] First Draft of V6OPS Meeting Agenda for IETF 102 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:55:26 -0000 --Apple-Mail=_E70DCE30-8F42-46E5-AA0C-24149459B829 Content-Type: multipart/mixed; boundary="Apple-Mail=_57A2E320-D5F0-4675-9C98-E565218A06B7" --Apple-Mail=_57A2E320-D5F0-4675-9C98-E565218A06B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The provisional IETF meeting agenda is at: https://datatracker.ietf.org/meeting/102/agenda.txt I enclose a first draft of the meeting agenda for v6ops, if you note = anything that you think should be added or updated please let the chairs = know at "v6ops-chairs@ietf.org" ". --Apple-Mail=_57A2E320-D5F0-4675-9C98-E565218A06B7 Content-Disposition: attachment; filename=agenda-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="agenda-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

IESG: Waiting for Writeup

WG: Updated WG Document

Individual Submission: Updated

Tue Jun 19 06:04:41 2018

--Apple-Mail=_57A2E320-D5F0-4675-9C98-E565218A06B7-- --Apple-Mail=_E70DCE30-8F42-46E5-AA0C-24149459B829 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+AFAlso0wgACgkQEhdRnd2G P+BVaw/9GWE9Ob65czN37Reiidglid60m60dDR1GUyHPdNXC0wQThKvR44xNEWPZ JKrRohA17Jy7X1FkELisLKzE2a3Epj0a5hXJPzuSIeybaNP/ZnljydCuISlKZjwn al0Oe2/EBEFrFps4MrV7njwn3XPPFT7+vobvvoXB0tAwFtwAlRwOOoROX4BXVKyI O3YFcYPUvANmUDn1Xje1gh1iVDEcfjNpA2RfVG6yjDHyL19x+z/3su4/ThCk5zTA 9A6tAFxe9BZVONcKwFureHI2v6NgBWCXSdLPAet8WV19TRuKS9wFzclzKCNSM4zX +WUY5xMUECwJClz/Mh4ipWGvus8ijkEumR+oCK7BSMrwsO61MzMx+FbD4zKrwxd0 hFOlMD9cfHNNyZHEYWT+depp11sulaI1iRnuWLUGeq5A5/uwMF2hnd8PVRWtagV7 MwWLcVET7g6SrVJhka2zC3/gc5v/A68/QoLHnthlG8Fx/+/nd5bXk/Lafj8Y7ief 0y/Bag1CdgzpGCbfKa24C+qT3Y6f0jXO2wum7SMII7H/bZILw7NH40n6NiYjqsbZ skz/onAtYHMtdiOJEJtY65lY1+jQ4iUH5ZSMNOcccbEixBhHAtYOCUFAlzLUSNwD U5fD83+sHz+E4IR9FpzAUMAJGygHt5aaHoOKJ3SC/h0IlzJq5hw= =wTGX -----END PGP SIGNATURE----- --Apple-Mail=_E70DCE30-8F42-46E5-AA0C-24149459B829-- From nobody Tue Jun 19 02:58: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 E4E36130DC5 for ; Tue, 19 Jun 2018 02:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 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, T_HTML_ATTACH=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phruq75gRl8D for ; Tue, 19 Jun 2018 02:58:31 -0700 (PDT) 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 0D6DF1277D2 for ; Tue, 19 Jun 2018 02:58:31 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id w8-v6so9166662ply.8 for ; Tue, 19 Jun 2018 02:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:mime-version:subject:message-id:date:to; bh=tLQGZHpu404DB1u4L+HIVbWJtlDaSzqS8OfJ/rU+xiM=; b=MDud/TiWhToUAuklYfQw8EeXbHRHdZBd/zM7zMVjVESivFZEuiLlAgiyRgVqPnfR4q CtZVxwrhvtpB8m0V2hfw4CDyoOkJ/luH3ccciGzGvueWdtHI37XNwwZ01bFUd29e2mqs 2MoRYyjtIa4tN8bq6/H2yoxTAmUUQbTYWNVyOlR4nhY96BPVWMyZRPDCCUlTop2NFBFR 7AJLe1rNYcU88qFSjekrSAT77FBu/e7gdjPtv180g5fI829x47b4f4nJS7CX/WBc03kC Y65/2n4WZdvpZPfXbKbnhmy8MtJmwoXcLF5tAeuuLQi3nT5/8PdqknhiH6exDDzPvViA CJ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:message-id :date:to; bh=tLQGZHpu404DB1u4L+HIVbWJtlDaSzqS8OfJ/rU+xiM=; b=S1J7es0UjmJchsztTx7d37zIdYGMmbYjrOv2mQYUn3osp9UpuV3yEg4/IrlZzAS0OE 7BHe0VamNHEHNT998gpI0Csv0LHKB0T2QvNA6ZFZMjZJoKk5V0aLaIBM5ZZLBi84DRD5 VdxG7WIuIccaTc5qY4Vhqd+qFYrxLt998UN4+5JwJ4wh2GrDmIwxyLQtrMHmyFZQniSe RqWmm8e8Xk7d1aEaN+8WOSWOZUfxIoFJaHGVtgus4MI83ZURYbS9rWU5xhicQ2jbAMcu oyF59GJKpB1kjhHelqBXSleEoA6XsdMmEubdKyKtcbRFXP32T/qGOAv5IqvbaMs7WhLt 6EwA== X-Gm-Message-State: APt69E3oouf7hz67b+wNbL8eMb+wgFr4ScvdbdOmd2P66fT2O+9b5TFC ewuF4KtvH0Z15cIICHwWjUh5mVTU X-Google-Smtp-Source: ADUXVKKGZaidSlnO4oaIx6DghdhiPv9sPoMrDGfxqRZuvnQDTLZpifC506DTiDW8JroYPOG3upld+A== X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr17955319pls.237.1529402310619; Tue, 19 Jun 2018 02:58:30 -0700 (PDT) Received: from [172.17.2.22] (125-227-167-218.HINET-IP.hinet.net. [125.227.167.218]) by smtp.gmail.com with ESMTPSA id z3-v6sm25614815pfn.36.2018.06.19.02.58.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 02:58:29 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_39EC7B68-8668-4B4B-8653-2C0E4FB16FBD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: V6ops Chairs Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <2A9DF541-DB24-4D1A-9ED5-8074A04E67A4@gmail.com> Date: Tue, 19 Jun 2018 17:58:27 +0800 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] First Draft of V6OPS Meeting Agenda for IETF 102 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:58:34 -0000 --Apple-Mail=_39EC7B68-8668-4B4B-8653-2C0E4FB16FBD Content-Type: multipart/mixed; boundary="Apple-Mail=_E0B19B0F-075F-4EBF-A624-B52386516C0D" --Apple-Mail=_E0B19B0F-075F-4EBF-A624-B52386516C0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And of course I sent the wrong file. Agenda-v6ops.html tells us what = drafts are posted and possible to include. The actual proposed agenda is = v6ops-102.html. My apologies. The provisional IETF meeting agenda is at: https://datatracker.ietf.org/meeting/102/agenda.txt I enclose a first draft of the meeting agenda for v6ops, if you note = anything that you think should be added or updated please let the chairs = know at "v6ops-chairs@ietf.org" ". --Apple-Mail=_E0B19B0F-075F-4EBF-A624-B52386516C0D Content-Disposition: attachment; filename=agenda-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="agenda-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

IESG: Waiting for Writeup

WG: Updated WG Document

Individual Submission: Updated

Tue Jun 19 06:04:41 2018

--Apple-Mail=_E0B19B0F-075F-4EBF-A624-B52386516C0D Content-Disposition: attachment; filename=v6ops-102.html Content-Type: text/html; x-unix-mode=0644; name="v6ops-102.html" Content-Transfer-Encoding: 7bit IPv6 Operations - IETF 102

IPv6 Operations - IETF 102

World IPv6 Trends
George Michaelson, APNIC
Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service
2018-06-13, <draft-ietf-v6ops-transition-ipv4aas>
Requirements for IPv6 Routers
2018-05-26 , <draft-ietf-v6ops-ipv6rtr-reqs>
Multi-Addressing Considerations for IPv6 Prefix Delegation
2018-06-14, <draft-templin-v6ops-pdhost>
IPoE Client Health Checking
2018-06-12 , <draft-patterson-intarea-ipoe-health>

Draft Status

The status of v6ops drafts, both working group drafts (draft-ietf-v6ops-*) and individual submissions to the working group (draft-<author>-v6ops-*), may be determined from https://datatracker.ietf.org/wg/v6ops/.

--Apple-Mail=_E0B19B0F-075F-4EBF-A624-B52386516C0D-- --Apple-Mail=_39EC7B68-8668-4B4B-8653-2C0E4FB16FBD 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+AFAlso08QACgkQEhdRnd2G P+A+VhAAtA6wksvBJvANQ+YwZzG81sVaSbJa+tzDXiwjNOxNqaaeoQ1BOjqpDplL v+/sTNbrk2A+yYUOadmxveE8e/MPhno5uCj70zk4y37sSHqGk2GFvt41tPUoCPxi rDwa4INDe+ZWQGOhMbwXV1+ponqZl5ZCe0XCUofcGTM1mhjrQPQvSgzibTsPCQ7J ofi5mcubuCVnyKQDlf7M3P/YkbR7sOJStk3pPmlLuelqRTuBpVU7d9uW7UTfMTDB fGZBmW+vfi9FZg+Z9n6xQVmnmU/VE5k5vbiGwKOBQeb0JWqPCEI5Wj7VE6GqLrpA 3n1rpS9ugTTbZg3j8NqvEnepoAhx0Nel9ZKmkZEdo7LOo6xRFmv4OOdMFHb051bD 1+86L92LnUN+pVj+yOzuoyuNNrorLtV8QRlQ46TCH9gdK+xPAt5plOZ9YQgXWM3w 0y8sqzIKyMJZMJ02xQUW8UQF8H9aW/rfoK5IcF6oBUxh424WOcsR+NtRb3dqJPnt YDch058TB4X+GL7nbuanxgTPIdUAPrWklpblO/2nNhlNbh+7Gh3HlYnmS1xqvrFy e1U6mTsaMMidjAWSGxl2qJsCEW5xoC5uQrfVcKPhZW1uN7VCa0I59hGWzrZ5TBBo bJXE7WQbzYwv28kinOo2aOKvAbcVoowNZ8l9IOZ8nWgnKTUcQcg= =Akj6 -----END PGP SIGNATURE----- --Apple-Mail=_39EC7B68-8668-4B4B-8653-2C0E4FB16FBD-- From nobody Tue Jun 19 04:40: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 1EA9D130DDC for ; Tue, 19 Jun 2018 04:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WNriwYDl6Wu for ; Tue, 19 Jun 2018 04:40:02 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63761277C8 for ; Tue, 19 Jun 2018 04:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529408398; x=1530013198; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=oi4T6Jg/JRvbAQjwp89FlUzCuTsm5+evlpCvdqwzQW0=; b=TbP7Uyzoegc1g 8jtekGh76eGs7IbVEtweofi4obTIBPUkx6rca56doGG2TTwUDeXftksIHA3J6G25 gg0ak/hXwqP5EpbbWTmfuJ9FQx2QnLLHP6bvCSJr82fnCybQ9mOppiuOiyA8Vrzj mM3aiYZDCJfcuFx2KzhNTi7JlMttS0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 19 Jun 2018 13:39:58 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 19 Jun 2018 13:39:57 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005792015.msg for ; Tue, 19 Jun 2018 13:39:56 +0200 X-MDRemoteIP: 2001:470:1f09:495:69ab:27f8:c842:8ca9 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 19 Jun 2018 13:39:56 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1708280bf9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Tue, 19 Jun 2018 13:39:55 +0200 From: JORDI PALET MARTINEZ To: CC: "v6ops@ietf.org" Message-ID: <9EC7B973-66F6-4F02-AD41-43B361C551CC@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF472EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF472EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 11:40:06 -0000 Hi Med, Responding below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: martes, 19 de junio de 2018, 7:41 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Hi Jordi,=20 =20 Please see inline.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] > Envoy=C3=A9 : lundi 18 juin 2018 19:05 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 3.txt >=20 > Hi Med, >=20 >=20 >=20 > Thanks a lot for your inputs. >=20 >=20 >=20 > I've few comments: >=20 > 1) The requirements language is the same as it was used in RFC7084. W= e > believe it makes a lot of sense to follow that. >=20 =20 [Med] My comment was about "Unlike other IETF documents,". As you menti= oned, the core text is also in 7084 which is an IETF document! Please consi= der deleting that mention.=20 I see now what you mean. Keeping only: 1.1. Requirements Language - Special Note The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as described in RFC 2119 [RFC2119]. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. As such, the document points to several other specifications to provide additional guidance to implementers regarding any protocol implementation required to produce a successful IPv6 Transition CE Router that interoperates successfully with a particular subset of currently deploying and planned common IPv6-only access networks. I've also added (from RFC6092): Additionally, the key word "DEFAULT" is to be interpreted in this document as pertaining to a configuration as applied by a vendor, prior to the administrator changing it for its initial activation. And changed in the document a couple of usages of default to DEFAULT, so it= is more "visible". =20 >=20 >=20 > 2) Some of the comments are related to the usage of expressions such = as > services vs servers, transition vs service continuity, etc. The autho= rs > consider that it is good to use those interchangeable wordings, becau= se for > example, if we don't mention transition, a reader may be confused > understanding that this is not regarding transition but a new problem > "service continuity". Anyway, we will take a look again into this, an= d also > seek for other comments from the WG. >=20 >=20 >=20 > 3) Will clarify anything that doesn't parse easily from your inputs. >=20 >=20 >=20 > 4) You're right regarding the numbering of new General and LAN requir= ements, > there is no reason now to follow the numbering of RFC7084, we will st= art from > 1. >=20 >=20 >=20 > 5) We believe that it makes sense that in the DEFAULT config, accordi= ng with > the discussion in the list, transition is disabled, so we avoid possi= ble > conflicts, unless the ISP turns it on (following RFC8026) or the user= (by > means of GUI or CLI). =20 [Med] RFC8026 assumes that corresponding options are requested. If a me= chanism is disabled, I assume the corresponding DHCP option won't be includ= ed in the request to the server. TRANS-1 is problematic. =20 I still don't understand the expected behavior. Ok, I understand now your point and I believe we have both in mind the same= behavior, but the text is not clear. What we want is that: 1) The corresponding options for each supported transition mechanism are re= quested. 2) However, the mechanism is DISABLED at the time being (no packets forward= ed yet, no routing entries, etc.). 3) Until the RFC8026 mechanisms decides which ones should be actually ENABL= ED. 4) Then the CE ENABLE those (and configures routing, starts forwarding, etc= .). At this way, if the ISP doesn't support *any* or don't want the CE to enabl= e any, will be able to do it. So, an alternative wording to clarify this: TRANS-1: All the supported transition mechanisms MUST be configured by DEFAULT by the IPv6 Transition CE Router via the relevant opt= ions=20 for each one, however they MUST be disabled until by means of TRANS-4, decides which ones are enabled/disabled. and TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which will allow enabling/disabling each transition mechanism. Also, maybe is better to change the order of the TRANS requirements so thos= e two are following each other. =20 >=20 >=20 >=20 > 6) The code considerations section was requested in v6ops to be keep = as part > of the document, not an annex. We are happy to change that again if t= hat's > the WG decision. >=20 >=20 >=20 > We will wait a few extra days for any further inputs before submittin= g a new > version (before the cut-off). >=20 >=20 >=20 > Thanks ! >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de > >=20 > Fecha: lunes, 18 de junio de 2018, 14:27 >=20 > Para: JORDI PALET MARTINEZ >=20 > CC: "v6ops@ietf.org" >=20 > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 3.txt >=20 >=20 >=20 > Hi Jordi, >=20 >=20 >=20 > FWIW, please find some comments to this draft at: >=20 >=20 >=20 > pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master= /draft- > ietf-v6ops-transition-ipv4aas-03-rev%20Med.pdf >=20 > doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/= draft- > ietf-v6ops-transition-ipv4aas-03-rev%20Med.doc >=20 >=20 >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > > -----Message d'origine----- >=20 > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI = PALET > MARTINEZ >=20 > > Envoy=C3=A9 : samedi 16 juin 2018 08:57 >=20 > > =C3=80 : v6ops@ietf.org >=20 > > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv= 4aas- > 03.txt >=20 > > >=20 > > Hi all, >=20 > > >=20 > > >=20 > > >=20 > > As indicated a couple of day ago, we have updated this document= , so > instead >=20 > > of an update of RFC8026 and a new option code, we only need to = ask IANA > to >=20 > > use a NAT64 existing one for the RFC8026 priority table. >=20 > > >=20 > > >=20 > > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition- >=20 > > ipv4aas/?include_text=3D1 >=20 > > >=20 > > >=20 > > >=20 > > Let's know any comments you have. >=20 > > >=20 > > >=20 > > >=20 > > Thanks! >=20 > > >=20 > > >=20 > > >=20 > > Regards, >=20 > > >=20 > > Jordi >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > =EF=BB=BF-----Mensaje original----- >=20 > > >=20 > > De: v6ops en nombre de drafts@ietf.org> >=20 > > >=20 > > Fecha: s=C3=A1bado, 16 de junio de 2018, 8:43 >=20 > > >=20 > > Para: >=20 > > >=20 > > CC: >=20 > > >=20 > > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas= -03.txt >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > A New Internet-Draft is available from the on-line Internet= -Drafts >=20 > > directories. >=20 > > >=20 > > This draft is a work item of the IPv6 Operations WG of the = IETF. >=20 > > >=20 > > >=20 > > >=20 > > Title : Requirements for IPv6 Customer Ed= ge > Routers to >=20 > > Support IPv4 Connectivity as-a-Service >=20 > > >=20 > > Authors : Jordi Palet Martinez >=20 > > >=20 > > Hans M.-H. Liu >=20 > > >=20 > > Masanobu Kawashima >=20 > > >=20 > > Filename : draft-ietf-v6ops-transition-ipv4aas-03.t= xt >=20 > > >=20 > > Pages : 20 >=20 > > >=20 > > Date : 2018-06-15 >=20 > > >=20 > > >=20 > > >=20 > > Abstract: >=20 > > >=20 > > This document specifies the IPv4 service continuity requ= irements > for >=20 > > >=20 > > an IPv6 Customer Edge (CE) router, either provided by th= e > service >=20 > > >=20 > > provider or thru the retail market. >=20 > > >=20 > > >=20 > > >=20 > > Specifically, this document extends the "Basic Requireme= nts for > IPv6 >=20 > > >=20 > > Customer Edge Routers" in order to allow the provisionin= g of > IPv6 >=20 > > >=20 > > transition services for the support of "IPv4 as-a-Servic= e" > (IPv4aaS) >=20 > > >=20 > > by means of new transition mechanisms. The document onl= y covers >=20 > > >=20 > > transition technologies for delivering IPv4 in IPv6-only= access >=20 > > >=20 > > networks, commonly called "IPv4 as-a-Service" (IPv4aaS),= as > required >=20 > > >=20 > > in a world where IPv4 addresses are no longer available,= so > hosts in >=20 > > >=20 > > the customer LANs with IPv4-only or IPv6-only applicatio= ns or >=20 > > >=20 > > devices, requiring to communicate with IPv4-only service= s at the >=20 > > >=20 > > Internet, are still able to do so. >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > The IETF datatracker status page for this draft is: >=20 > > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transitio= n- > ipv4aas/ >=20 > > >=20 > > >=20 > > >=20 > > There are also htmlized versions available at: >=20 > > >=20 > > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv= 4aas-03 >=20 > > >=20 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-tran= sition- >=20 > > ipv4aas-03 >=20 > > >=20 > > >=20 > > >=20 > > A diff from the previous version is available at: >=20 > > >=20 > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transi= tion- > ipv4aas-03 >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > Please note that it may take a couple of minutes from the t= ime of >=20 > > submission >=20 > > >=20 > > until the htmlized version and diff are available at > tools.ietf.org. >=20 > > >=20 > > >=20 > > >=20 > > Internet-Drafts are also available by anonymous FTP at: >=20 > > >=20 > > ftp://ftp.ietf.org/internet-drafts/ >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > >=20 > > v6ops mailing list >=20 > > >=20 > > v6ops@ietf.org >=20 > > >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > ********************************************** >=20 > > IPv4 is over >=20 > > Are you ready for the new Internet ? >=20 > > http://www.consulintel.es >=20 > > The IPv6 Company >=20 > > >=20 > > This electronic message contains information which may be privi= leged or >=20 > > confidential. The information is intended to be for the exclusi= ve use > of the >=20 > > individual(s) named above and further non-explicilty authorized > disclosure, >=20 > > copying, distribution or use of the contents of this informatio= n, even > if >=20 > > partially, including attached files, is strictly prohibited and= will be >=20 > > considered a criminal offense. If you are not the intended reci= pient be > aware >=20 > > that any disclosure, copying, distribution or use of the conten= ts of > this >=20 > > information, even if partially, including attached files, is st= rictly >=20 > > prohibited, will be considered a criminal offense, so you must = reply to > the >=20 > > original sender to inform about this communication and delete i= t. >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > v6ops mailing list >=20 > > v6ops@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be > considered a criminal offense. If you are not the intended recipient = be aware > that any disclosure, copying, distribution or use of the contents of = this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply = to the > original sender to inform about this communication and delete it. >=20 >=20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jun 19 09:15: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 65C50130E16 for ; Tue, 19 Jun 2018 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 oQxidbq4LHGV for ; Tue, 19 Jun 2018 09:15:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01060130F76 for ; Tue, 19 Jun 2018 09:15:41 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id n7-v6so1196288itn.1 for ; Tue, 19 Jun 2018 09:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=NOLFnF+N7e35+LWVjZgNK7VenDjTILGRj50fVixGcY4=; b=FmyKgXLFWHxQvEw747pB4eqgH4+zq7djX/mUlLi2hz6DborinX+4OUx3YntVumoa+s qtXbVrb+hyOs+obsmxKfCcUM/7HfajaiNRXKK4+e6Qjp2giWj/W87uiMznJz4PnmH+yF 9Acio6C2hn92eF9aCqoUTEbxEQxYqHXiXkuwF2f2P5JdVf1D1OiMNQ0fmEGgRwTQblgs 4C1q+yRDSDFUL7e3aJDEmjEvdRCtTquu8El4iW5qiqIuBiwxHq45aMXzeXZ8UenuEGJg vpI6VyQvo6J8rIMRYRviczhNwEjNxRL5Ut8L4ExCRiW8fbdEPqge5wOHP7LcGKPDTDxH cRbQ== 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:content-transfer-encoding; bh=NOLFnF+N7e35+LWVjZgNK7VenDjTILGRj50fVixGcY4=; b=jz31fvsPTwGKgmgRM+UCSng7s056h4mL1NulesmcMrYo6TEZpPtxOeGR4DOeF5wJGn FNKXc5yjluFqfjVWLCyo7xgZHJSdGZcxfOlMEzl5PjZYn2PPRwASJgYMW9k94jxcI4si tefImglwdmH1aLnU+smBrN/7dopMzXFeDMDEHtJJvOQP1rBb3D84tXICi5GnG4zu/ABP gNh6d1t7GPcZzh/28FxrbjqF2gU0lu6kHipj6YAX5rIzTxbp29Mn1F5HU2NIcBRwcnFU ePQhWXLeA/b/8Uz5jMX8nogIuIzhpoFJ1J7JktQQnv0oOgQuHm1SqalCC015TEVJwz9C SKpA== X-Gm-Message-State: APt69E01xTNhn2BP85LhRZplDE2uhTm12uBrBlWSnq8C+JlEnrpsqOdV 97wVkLePLPsEAx3hXGqj0N8IAC3R X-Google-Smtp-Source: ADUXVKL84pulI06Sqr2CVnrB6u4ZGrMdZXIV66FNW6KGz+eOeCBUYem6hUMR9QyAdbENSGgHhZSoTg== X-Received: by 2002:a24:5f10:: with SMTP id r16-v6mr13494019itb.73.1529424940311; Tue, 19 Jun 2018 09:15:40 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id w8-v6sm12942iof.84.2018.06.19.09.15.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 09:15:39 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id g22-v6so723434iob.7 for ; Tue, 19 Jun 2018 09:15:39 -0700 (PDT) X-Received: by 2002:a6b:8e0d:: with SMTP id q13-v6mr14034694iod.169.1529424939507; Tue, 19 Jun 2018 09:15:39 -0700 (PDT) MIME-Version: 1.0 References: <152942445652.30032.15080648913308255687.idtracker@ietfa.amsl.com> <8171C92C-3979-4889-9B8E-2695080CDA51@sky.uk> In-Reply-To: <8171C92C-3979-4889-9B8E-2695080CDA51@sky.uk> From: Richard Patterson Date: Tue, 19 Jun 2018 17:15:27 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 16:15:44 -0000 Thanks for the comments on and off the v6ops list, we've published a new version of draft-patterson-intarea-ipoe-health. The major changes can summarised as: - Emphasised preference for use of BFD echo as the health check mechanism. - Removed lifetime expiration from Behaviour 2 and clarified usage. - Updated Behaviour 3 with instructions for whilst mid-renew/rebind. - Reworded multihoming section. - Added Acknowledgements. Please continue providing feedback, and if anyone has a relationship with DHCP client developers, or CPE vendors, we'd love to start a dialogue there too. -Richard =EF=BB=BFOn 19/06/2018, 17:07, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-patterson-intarea-ipoe-health-02.txt has been successfully submitted by Richard Patterson and posted to the IETF repository. Name:draft-patterson-intarea-ipoe-health Revision:02 Title:IPoE Client Health Checking Document date:2018-06-19 Group:Individual Submission Pages:13 URL: https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-02= .txt Status: https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ Htmlized: https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-patterson-intarea-ipoe-health-02 Abstract: PPP over Ethernet clients have the functionality to detect path unavailability by using PPP Keepalives. IP over Ethernet does not have this functionality, and it's not specified when an IP over Ethernet client should consider its WAN connectivity down, unless there is a physical layer link down event. This document describes a way for IP over Ethernet clients to achiev= e connectivity validation, similar to that of PPP over Ethernet, by using BFD Echo, or ARP and Neighbor Discovery functions. Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jun 19 09:40: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 6D876130DF7 for ; Tue, 19 Jun 2018 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 c9EHeFogVpP6 for ; Tue, 19 Jun 2018 09:40:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 1C302130DEE for ; Tue, 19 Jun 2018 09:40:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FyAAB4MSlb/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ1VGJtEigKg2+IBIxRggCUexSBKToBCyMJAoQ+AheCWCE0GAE?= =?us-ascii?q?CAQEBAQEBAgICaRwMgmgxBAcDDCEJAjABAQEBAQEjAg81EgEBGAEBAQEDEhERO?= =?us-ascii?q?gQFDgQCAQgNBAQBAQECAgYdAwICAjAUAQgIAgQBEggagwSBfwEOoiWJbIIcGgK?= =?us-ascii?q?ILIFogQuFPwGCCYFVPoQbgxMCAgEXgS4aFYJqMYIkAow+jGEJAoV7ilFBgz+CW?= =?us-ascii?q?YUlihWHPoFBOYFScBUaIYJDCYIYFxGDNIUUhT5vgRWIdSuBAQGBGQEB?= X-IPAS-Result: =?us-ascii?q?A2FyAAB4MSlb/yYyC4ddGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?1VGJtEigKg2+IBIxRggCUexSBKToBCyMJAoQ+AheCWCE0GAECAQEBAQEBAgICa?= =?us-ascii?q?RwMgmgxBAcDDCEJAjABAQEBAQEjAg81EgEBGAEBAQEDEhEROgQFDgQCAQgNBAQ?= =?us-ascii?q?BAQECAgYdAwICAjAUAQgIAgQBEggagwSBfwEOoiWJbIIcGgKILIFogQuFPwGCC?= =?us-ascii?q?YFVPoQbgxMCAgEXgS4aFYJqMYIkAow+jGEJAoV7ilFBgz+CWYUlihWHPoFBOYF?= =?us-ascii?q?ScBUaIYJDCYIYFxGDNIUUhT5vgRWIdSuBAQGBGQEB?= X-IronPort-AV: E=Sophos;i="5.51,243,1526356800"; d="scan'208";a="290132890" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Jun 2018 12:40:41 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 12:40:41 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 19 Jun 2018 12:40:41 -0400 From: "Mudric, Dusan (Dusan)" To: Richard Patterson , "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt Thread-Index: AQHUB+juspXIP/Y1rE2+MYJK9cVdoaRnwwvw Date: Tue, 19 Jun 2018 16:40:40 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB09CBE@AZ-US1EXMB03.global.avaya.com> References: <152942445652.30032.15080648913308255687.idtracker@ietfa.amsl.com> <8171C92C-3979-4889-9B8E-2695080CDA51@sky.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 16:40:48 -0000 SGkgUmljaGFyZCwNCg0KSSBoYXZlIGEgZmV3IG1vcmUgY29tbWVudHM6DQoNCi0JV2hhdCBpcyB0 aGUgYmVoYXZpb3IgZm9yIOKAnElmIHRoZSBJUG9FIGNsaWVudCBpcyBhbHJlYWR5IGluIHRoZSBy ZW5ldyBvciByZWJpbmQgc3RhdGUgd2hlbiBCZWhhdmlvdXIgMiBpcyB0cmlnZ2VyZWTigJ0/IFNo b3VsZCBpdCBiZSB0aGUgc2FtZSBhcyBCZWhhdmlvciAzPw0KLQlTSE9VTEQgdGhlIGNsaWVudCB1 c2UgUkFQSUQgQ09NTUlUIG9wdGlvbiBmb3IgQmVoYXZpb3JzIDIgYW5kIDM/DQoNCi0JTWlzc2lu ZyBhIGRpYWdyYW0gZm9yIHRoZSBwcm9ibGVtIHN0YXRlbWVudDogQ2FuIHlvdSBzaG93IHBsZWFz ZSwgdXNpbmcgYSBzaW1wbGUgZGlhZ3JhbSwgaG93IERIQ1B2NiBsZWFzZSAgYmVjb21lcyBzdGFs ZT8NCi0JUHJvdmlkZSBkaWFncmFtcyBmb3IgYWxsIG9wdGlvbnMsIHNob3dpbmcgaG93IGEgY2xp ZW50IHJlY292ZXJzIGFmdGVyIGFuIGVkZ2Ugcm91dGVyIG91dGFnZS4gRm9yIGV4YW1wbGUsIGlm IDMuMyBORCBOVUQgZmluZHMgdGhlIGVkZ2Ugcm91dGVyIGlzIHVucmVhY2hhYmxlLCBzaG93IHRo ZSBiZW5lZml0cyBvZiBSRU5FVyBhbmQgU09MSUNJVCBvcHRpb25zIGFuZCBob3cgdGhlIGNsaWVu dCB3aWxsIGNvbW11bmljYXRlIHRvIG9mZi1saW5rIGRlc3RpbmF0aW9ucyB1c2luZyB0aGUgb2xk IG9yIGEgbmV3IERIQ1B2NiBhZGRyZXNzLg0KLQlQcm92aWRlIGEgZGlhZ3JhbSBzaG93aW5nIGhv dyBhIHJvdXRlciBvdXRhZ2UgYmV0d2VlbiBhIFJlbGF5IEFnZW50IGFuZCBJU1AgY2FuIGJlIGRl dGVjdGVkIChpLmUuIFJBIGZyb20gdGhlIGVkZ2Ugcm91dGVyKSBhbmQgaG93IHRoZSBjbGllbnQg Y2FuIHJlY292ZXIgY29ubmVjdGl2aXR5IHRvIG9mZi1saW5rIGRlc3RpbmF0aW9ucy4NCg0KUmVn YXJkcywNCkR1c2FuLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQN Cj4gUGF0dGVyc29uDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggMTI6MTUgUE0NCj4g VG86IHY2b3BzQGlldGYub3JnIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbdjZv cHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGF0dGVyc29uLWludGFyZWEt aXBvZS0NCj4gaGVhbHRoLTAyLnR4dA0KPiANCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMgb24g YW5kIG9mZiB0aGUgdjZvcHMgbGlzdCwgd2UndmUgcHVibGlzaGVkIGENCj4gbmV3IHZlcnNpb24g b2YgZHJhZnQtcGF0dGVyc29uLWludGFyZWEtaXBvZS1oZWFsdGguDQo+IFRoZSBtYWpvciBjaGFu Z2VzIGNhbiBzdW1tYXJpc2VkIGFzOg0KPiAgLSBFbXBoYXNpc2VkIHByZWZlcmVuY2UgZm9yIHVz ZSBvZiBCRkQgZWNobyBhcyB0aGUgaGVhbHRoIGNoZWNrDQo+IG1lY2hhbmlzbS4NCj4gIC0gUmVt b3ZlZCBsaWZldGltZSBleHBpcmF0aW9uIGZyb20gQmVoYXZpb3VyIDIgYW5kIGNsYXJpZmllZCB1 c2FnZS4NCj4gIC0gVXBkYXRlZCBCZWhhdmlvdXIgMyB3aXRoIGluc3RydWN0aW9ucyBmb3Igd2hp bHN0IG1pZC1yZW5ldy9yZWJpbmQuDQo+ICAtIFJld29yZGVkIG11bHRpaG9taW5nIHNlY3Rpb24u DQo+ICAtIEFkZGVkIEFja25vd2xlZGdlbWVudHMuDQo+IA0KPiBQbGVhc2UgY29udGludWUgcHJv dmlkaW5nIGZlZWRiYWNrLCBhbmQgaWYgYW55b25lIGhhcyBhIHJlbGF0aW9uc2hpcA0KPiB3aXRo IERIQ1AgY2xpZW50IGRldmVsb3BlcnMsIG9yIENQRSB2ZW5kb3JzLCB3ZSdkIGxvdmUgdG8gc3Rh cnQgYQ0KPiBkaWFsb2d1ZSB0aGVyZSB0b28uDQo+IA0KPiAtUmljaGFyZA0KPiANCj4gDQo+IO+7 v09uIDE5LzA2LzIwMTgsIDE3OjA3LCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCj4gDQo+IA0KPiAgICAgQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXBhdHRlcnNvbi1pbnRhcmVhLWlwb2UtaGVhbHRoLTAyLnR4dA0KPiAg ICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSaWNoYXJkIFBhdHRlcnNvbiBh bmQgcG9zdGVkIHRvIHRoZQ0KPiAgICAgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gICAgIE5hbWU6 ZHJhZnQtcGF0dGVyc29uLWludGFyZWEtaXBvZS1oZWFsdGgNCj4gICAgIFJldmlzaW9uOjAyDQo+ ICAgICBUaXRsZTpJUG9FIENsaWVudCBIZWFsdGggQ2hlY2tpbmcNCj4gICAgIERvY3VtZW50IGRh dGU6MjAxOC0wNi0xOQ0KPiAgICAgR3JvdXA6SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ICAgICBQ YWdlczoxMw0KPiAgICAgVVJMOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfZHJh ZnQtMkRwYXR0ZXJzb24tMkRpbnRhcmVhLTJEaXBvZS0NCj4gMkRoZWFsdGgtDQo+IDJEMDIudHh0 JmQ9RHdJR2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQw0K PiByaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09Rkp3UUJ6SUxXOFY4ZS0NCj4gMkFxSlkwUjVF WXpnZU9QTllFamJRTlpWckdYQUEmcz16MlNESVp4NVpWcWREZVgtDQo+IEY2RjY3VVlhN1F2b1lx enROV0lKYXhxTEVubyZlPQ0KPiAgICAgU3RhdHVzOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19k b2NfZHJhZnQtMkRwYXR0ZXJzb24tMkRpbnRhcmVhLTJEaXBvZS0NCj4gMkRoZWFsdGhfJmQ9RHdJ R2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjMNCj4gaUNyaElv VVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09Rkp3UUJ6SUxXOFY4ZS0NCj4gMkFxSlkwUjVFWXpnZU9Q TllFamJRTlpWckdYQUEmcz12N2FYcHVBUnhOU3pwQTljUmtnWWtfenJDbWE5YQ0KPiBDUzN6d0lB T1l4WTZQcyZlPQ0KPiAgICAgSHRtbGl6ZWQ6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQt MkRwYXR0ZXJzb24tMkRpbnRhcmVhLTJEaXBvZS0yRGhlYWx0aC0NCj4gMkQwMiZkPUR3SUdhUSZj PUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaEkNCj4gb1VXQjhZ TFpVMjMwMjlzTVFHUTJrWSZtPUZKd1FCeklMVzhWOGUtDQo+IDJBcUpZMFI1RVl6Z2VPUE5ZRWpi UU5aVnJHWEFBJnM9YnhhT2JRZzdDZVl4WllWay1EclNvMHNuaS0NCj4gQkFTOHgzTXdoN3U0bEp4 NWcmZT0NCj4gICAgIEh0bWxpemVkOg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9k cmFmdC0yRHBhdHRlcnNvbi0yRGludGFyZWEtMkRpcG9lLQ0KPiAyRGhlYWx0aCZkPUR3SUdhUSZj PUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaQ0KPiBDcmhJb1VXQjhZ TFpVMjMwMjlzTVFHUTJrWSZtPUZKd1FCeklMVzhWOGUtDQo+IDJBcUpZMFI1RVl6Z2VPUE5ZRWpi UU5aVnJHWEFBJnM9Zy0NCj4gaUR5SHNnX0hDM0htNEdEeXdZMU9jekRqemtueWlTbEtMYk9JNVpN WDgmZT0NCj4gICAgIERpZmY6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0zRGRyYWZ0 LTJEcGF0dGVyc29uLTJEaW50YXJlYS0yRGlwb2UtDQo+IDJEaGVhbHRoLQ0KPiAyRDAyJmQ9RHdJ R2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSQ0KPiBv VVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09Rkp3UUJ6SUxXOFY4ZS0NCj4gMkFxSlkwUjVFWXpnZU9Q TllFamJRTlpWckdYQUEmcz0xQWpmU1ZuTHRkQjZRUDY1OWNHOERuWUV1MTJCYg0KPiBEelFLU0c2 elpNX2JPWSZlPQ0KPiANCj4gICAgIEFic3RyYWN0Og0KPiAgICAgICAgUFBQIG92ZXIgRXRoZXJu ZXQgY2xpZW50cyBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBwYXRoDQo+ICAgICAg ICB1bmF2YWlsYWJpbGl0eSBieSB1c2luZyBQUFAgS2VlcGFsaXZlcy4gIElQIG92ZXIgRXRoZXJu ZXQgZG9lcyBub3QNCj4gICAgICAgIGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5LCBhbmQgaXQncyBu b3Qgc3BlY2lmaWVkIHdoZW4gYW4gSVAgb3Zlcg0KPiAgICAgICAgRXRoZXJuZXQgY2xpZW50IHNo b3VsZCBjb25zaWRlciBpdHMgV0FOIGNvbm5lY3Rpdml0eSBkb3duLCB1bmxlc3MNCj4gICAgICAg IHRoZXJlIGlzIGEgcGh5c2ljYWwgbGF5ZXIgbGluayBkb3duIGV2ZW50Lg0KPiANCj4gICAgICAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgd2F5IGZvciBJUCBvdmVyIEV0aGVybmV0IGNsaWVu dHMgdG8gYWNoaWV2ZQ0KPiAgICAgICAgY29ubmVjdGl2aXR5IHZhbGlkYXRpb24sIHNpbWlsYXIg dG8gdGhhdCBvZiBQUFAgb3ZlciBFdGhlcm5ldCwgYnkNCj4gICAgICAgIHVzaW5nIEJGRCBFY2hv LCBvciBBUlAgYW5kIE5laWdoYm9yIERpc2NvdmVyeSBmdW5jdGlvbnMuDQo+IA0KPiANCj4gDQo+ IA0KPiAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiAgICAgdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ ICAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGll dGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9 QkZwV1F3OGJzdUtwDQo+IGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlM WlUyMzAyOXNNUUdRMmtZJm09Rkp3DQo+IFFCeklMVzhWOGUtDQo+IDJBcUpZMFI1RVl6Z2VPUE5Z RWpiUU5aVnJHWEFBJnM9MTBRVk0wejhfR212bGxWbXBZUDNvazJ5NGxoWA0KPiBiTTFvQVlnYnFy WkZhcmsmZT0NCg== From nobody Tue Jun 19 13:02: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 DC870130E6E for ; Tue, 19 Jun 2018 13:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=helix-net-nz.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 LovjHMJfX26j for ; Tue, 19 Jun 2018 13:02:17 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC9A130E29 for ; Tue, 19 Jun 2018 13:02:17 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id d185-v6so1382118ioe.0 for ; Tue, 19 Jun 2018 13:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PzoVWNZmqJeFaiM18hDBBjqbqzE9geafHNdP2zlzm4M=; b=IksUrr0suOlpvGdMjS8aQmA/1IFYhURzs5k5bfiywaFczDG7dlG0/rYPCNLN4Q6Mrw B6JT+4DucokheIsGXC6wf7Vls/tShQNw4oPBYUuWSvDvyOmebEKLdVEs1Z9jHp6Tn13o BLqWYJF6Uan/xZVfloyox5rcuhwGy3bzwdCpiqILBTa1y8PlxmoHr9m50squ5GpD2joI cAu7UdFUTXUQTsdXAnRLfTByme62YCQDuK87m8pFhpOg1Z8575M4qJogACpj7hYP4Hxu CuO5TtrsXtpSkaMKxeMRdV1LLGlIvWDpI/ZFT6RhPNmCt1YWevVBd5vGFa9/rPD9i4YN tuoQ== 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:content-transfer-encoding; bh=PzoVWNZmqJeFaiM18hDBBjqbqzE9geafHNdP2zlzm4M=; b=IO1o8sufChR0UrE9glS0TDWzv3TB/dpOynUalzCW/uWCS4UotDQTLQORPulelgb4IC MbYrWR2qBJ06SrPbsptC3oQ+wIZHjX2UnuVe25BnxnQ8VIfnU2+9kkES3Z2EN3OMCH3S +sINKO6xkq9cpOnm+ZNDrMZf/SlsqqZMqysT4hfGa1o6GUYjmX4jY3R9AElY/F+aEk+6 F60NtUatSvzs2FpnLIwTTg2adIxTe78aOFyyD/jm6hE1S4THM/WMaT4ZEDDc6W+EZP2D eJzNk8kxo6QwPsX0Nll1fFRxC7Yn19OQeIWSYPA2ECwpxLzoMSkSWsv9EigOgZZUcgm3 aVvQ== X-Gm-Message-State: APt69E1ssx3t5F+5HDEn5dQvxmv+4WQC3MyUtRzBf/Rh+mkGq1RYLV2F S3kRcZNl5ZhrgbPgXvHzXOHfLBik2y8= X-Google-Smtp-Source: ADUXVKLZNw10LIqSiT6v584F534cOczWWU0MvuO+teGyHEoS+UYf/2O4yq2Ep5EtaTNGM/Z0k4SVjA== X-Received: by 2002:a6b:3ce:: with SMTP id e75-v6mr15394701ioi.194.1529438536192; Tue, 19 Jun 2018 13:02:16 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id c136-v6sm410632itc.36.2018.06.19.13.02.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:02:15 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id t5-v6so1355222ioa.8 for ; Tue, 19 Jun 2018 13:02:14 -0700 (PDT) X-Received: by 2002:a6b:8e0d:: with SMTP id q13-v6mr14693429iod.169.1529438534771; Tue, 19 Jun 2018 13:02:14 -0700 (PDT) MIME-Version: 1.0 References: <152942445652.30032.15080648913308255687.idtracker@ietfa.amsl.com> <8171C92C-3979-4889-9B8E-2695080CDA51@sky.uk> <9142206A0C5BF24CB22755C8EC422E459CB09CBE@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB09CBE@AZ-US1EXMB03.global.avaya.com> From: Richard Patterson Date: Tue, 19 Jun 2018 21:02:03 +0100 X-Gmail-Original-Message-ID: Message-ID: To: dmudric@avaya.com Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:02:22 -0000 Hi Dusan, Thanks again for your comments. I'll answer in-line below: On Tue, 19 Jun 2018 at 17:40, Mudric, Dusan (Dusan) wro= te: > - What is the behavior for =E2=80=9CIf the IPoE client is already i= n the renew or rebind state when Behaviour 2 is triggered=E2=80=9D? Should = it be the same as Behavior 3? This is less of a concern than Behaviour 3, as Behaviour 2 does not send a release. However I can include wording to allow any ongoing renew and rebind attempts to complete. Would that sufficiently cover it do you think? > - SHOULD the client use RAPID COMMIT option for Behaviors 2 and 3? We could add a "MAY use Rapid Commit", I'm just not sure if it's required, as it's already covered in RFC3315, Section 22.14. Perhaps adding a lowercase "may use rapid commit to expedite the recovery process" guidance as opposed to a requirement. What do you think? > - Missing a diagram for the problem statement: Can you show please,= using a simple diagram, how DHCPv6 lease becomes stale? > - Provide diagrams for all options, showing how a client recovers a= fter an edge router outage. For example, if 3.3 ND NUD finds the edge route= r is unreachable, show the benefits of RENEW and SOLICIT options and how th= e client will communicate to off-link destinations using the old or a new D= HCPv6 address. > - Provide a diagram showing how a router outage between a Relay Age= nt and ISP can be detected (i.e. RA from the edge router) and how the clien= t can recover connectivity to off-link destinations. I'll have a think about how best to depict these scenarios and get back to you with some suggestions. -Richard From nobody Tue Jun 19 13:10: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 2F9C1130ECD for ; Tue, 19 Jun 2018 13:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 kwJIenxLRBPF for ; Tue, 19 Jun 2018 13:10:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B73130E6E for ; Tue, 19 Jun 2018 13:10:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HEAAAzYilb/yYyC4dcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ1VIFPEigKg2+IBIxTggCUe4F4CyyEQAIXglghNBgBAgEBAQE?= =?us-ascii?q?BAQICAmkohSoBAQEBAxIREUMCDAQCAQgNBAQBAQECAgYdAwICAjAUAQgIAgQOB?= =?us-ascii?q?QgahQMBoX2JbIIcGgKILG2BC4dJgVU+hBuEd4J/MYIkApFIh1cJApBMhACCWYU?= =?us-ascii?q?lkVOBQTmBUnAVO4JDgkmOBm+BFYhzB4EnAYEZAQE?= X-IPAS-Result: =?us-ascii?q?A2HEAAAzYilb/yYyC4dcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?1VIFPEigKg2+IBIxTggCUe4F4CyyEQAIXglghNBgBAgEBAQEBAQICAmkohSoBA?= =?us-ascii?q?QEBAxIREUMCDAQCAQgNBAQBAQECAgYdAwICAjAUAQgIAgQOBQgahQMBoX2JbII?= =?us-ascii?q?cGgKILG2BC4dJgVU+hBuEd4J/MYIkApFIh1cJApBMhACCWYUlkVOBQTmBUnAVO?= =?us-ascii?q?4JDgkmOBm+BFYhzB4EnAYEZAQE?= X-IronPort-AV: E=Sophos;i="5.51,244,1526356800"; d="scan'208";a="285005476" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Jun 2018 16:10:19 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2018 16:10:19 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 19 Jun 2018 16:10:18 -0400 From: "Mudric, Dusan (Dusan)" To: Richard Patterson CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt Thread-Index: AQHUCAiEfj1Ek2bbL0egCjYLmcvZ0aRoAXEA Date: Tue, 19 Jun 2018 20:10:17 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB09E14@AZ-US1EXMB03.global.avaya.com> References: <152942445652.30032.15080648913308255687.idtracker@ietfa.amsl.com> <8171C92C-3979-4889-9B8E-2695080CDA51@sky.uk> <9142206A0C5BF24CB22755C8EC422E459CB09CBE@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:10:24 -0000 SGkgUmljaGFyZCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNClJlZ2FyZHMsDQpEdXNhbi4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSaWNoYXJkIFBhdHRlcnNvbiBb bWFpbHRvOnJpY2hhcmRAaGVsaXgubmV0Lm56XQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAy MDE4IDQ6MDIgUE0NCj4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0BhdmF5YS5j b20+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wYXR0ZXJz b24taW50YXJlYS0NCj4gaXBvZS1oZWFsdGgtMDIudHh0DQo+IA0KPiBIaSBEdXNhbiwNCj4gDQo+ IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjb21tZW50cy4gIEknbGwgYW5zd2VyIGluLWxpbmUgYmVs b3c6DQo+IA0KPiBPbiBUdWUsIDE5IEp1biAyMDE4IGF0IDE3OjQwLCBNdWRyaWMsIER1c2FuIChE dXNhbikgPGRtdWRyaWNAYXZheWEuY29tPg0KPiB3cm90ZToNCj4gPiAtICAgICAgIFdoYXQgaXMg dGhlIGJlaGF2aW9yIGZvciDigJxJZiB0aGUgSVBvRSBjbGllbnQgaXMgYWxyZWFkeSBpbiB0aGUg cmVuZXcgb3INCj4gcmViaW5kIHN0YXRlIHdoZW4gQmVoYXZpb3VyIDIgaXMgdHJpZ2dlcmVk4oCd PyBTaG91bGQgaXQgYmUgdGhlIHNhbWUgYXMNCj4gQmVoYXZpb3IgMz8NCj4gDQo+IFRoaXMgaXMg bGVzcyBvZiBhIGNvbmNlcm4gdGhhbiBCZWhhdmlvdXIgMywgYXMgQmVoYXZpb3VyIDIgZG9lcyBu b3QNCj4gc2VuZCBhIHJlbGVhc2UuICBIb3dldmVyIEkgY2FuIGluY2x1ZGUgd29yZGluZyB0byBh bGxvdyBhbnkgb25nb2luZw0KPiByZW5ldyBhbmQgcmViaW5kIGF0dGVtcHRzIHRvIGNvbXBsZXRl LiAgV291bGQgdGhhdCBzdWZmaWNpZW50bHkgY292ZXINCj4gaXQgZG8geW91IHRoaW5rPw0KW1tE dXNhbl1dIA0KW1tEdXNhbl1dIFllcy4gQmVoYXZpb3IgMiBjYW4gYmUgaW5pdGlhdGVkIGFueSB0 aW1lLCBpbmNsdWRpbmcgZHVyaW5nIFJFTkVXIG9yIFJFQklORCBwcm9jZXNzLiBESENQIGNsaWVu dCBiZWhhdmlvciBzaG91bGQgYmUgZGVmaW5lZCBmb3IgdGhhdCB1c2UgY2FzZS4NCg0KDQo+IA0K PiA+IC0gICAgICAgU0hPVUxEIHRoZSBjbGllbnQgdXNlIFJBUElEIENPTU1JVCBvcHRpb24gZm9y IEJlaGF2aW9ycyAyIGFuZCAzPw0KPiANCj4gV2UgY291bGQgYWRkIGEgIk1BWSB1c2UgUmFwaWQg Q29tbWl0IiwgSSdtIGp1c3Qgbm90IHN1cmUgaWYgaXQncw0KPiByZXF1aXJlZCwgYXMgaXQncyBh bHJlYWR5IGNvdmVyZWQgaW4gUkZDMzMxNSwgU2VjdGlvbiAyMi4xNC4NCj4gUGVyaGFwcyBhZGRp bmcgYSBsb3dlcmNhc2UgIm1heSB1c2UgcmFwaWQgY29tbWl0IHRvIGV4cGVkaXRlIHRoZQ0KPiBy ZWNvdmVyeSBwcm9jZXNzIiBndWlkYW5jZSBhcyBvcHBvc2VkIHRvIGEgcmVxdWlyZW1lbnQuICBX aGF0IGRvIHlvdQ0KPiB0aGluaz8NCltbRHVzYW5dXSANCltbRHVzYW5dXSBMb3dlcmNhc2UgJ21h eScgd2lsbCBzdWZmaWNlLg0KDQo+IA0KPiA+IC0gICAgICAgTWlzc2luZyBhIGRpYWdyYW0gZm9y IHRoZSBwcm9ibGVtIHN0YXRlbWVudDogQ2FuIHlvdSBzaG93IHBsZWFzZSwNCj4gdXNpbmcgYSBz aW1wbGUgZGlhZ3JhbSwgaG93IERIQ1B2NiBsZWFzZSAgYmVjb21lcyBzdGFsZT8NCj4gPiAtICAg ICAgIFByb3ZpZGUgZGlhZ3JhbXMgZm9yIGFsbCBvcHRpb25zLCBzaG93aW5nIGhvdyBhIGNsaWVu dCByZWNvdmVycyBhZnRlciBhbg0KPiBlZGdlIHJvdXRlciBvdXRhZ2UuIEZvciBleGFtcGxlLCBp ZiAzLjMgTkQgTlVEIGZpbmRzIHRoZSBlZGdlIHJvdXRlciBpcw0KPiB1bnJlYWNoYWJsZSwgc2hv dyB0aGUgYmVuZWZpdHMgb2YgUkVORVcgYW5kIFNPTElDSVQgb3B0aW9ucyBhbmQgaG93IHRoZQ0K PiBjbGllbnQgd2lsbCBjb21tdW5pY2F0ZSB0byBvZmYtbGluayBkZXN0aW5hdGlvbnMgdXNpbmcg dGhlIG9sZCBvciBhIG5ldw0KPiBESENQdjYgYWRkcmVzcy4NCj4gPiAtICAgICAgIFByb3ZpZGUg YSBkaWFncmFtIHNob3dpbmcgaG93IGEgcm91dGVyIG91dGFnZSBiZXR3ZWVuIGEgUmVsYXkNCj4g QWdlbnQgYW5kIElTUCBjYW4gYmUgZGV0ZWN0ZWQgKGkuZS4gUkEgZnJvbSB0aGUgZWRnZSByb3V0 ZXIpIGFuZCBob3cgdGhlDQo+IGNsaWVudCBjYW4gcmVjb3ZlciBjb25uZWN0aXZpdHkgdG8gb2Zm LWxpbmsgZGVzdGluYXRpb25zLg0KPiANCj4gSSdsbCBoYXZlIGEgdGhpbmsgYWJvdXQgaG93IGJl c3QgdG8gZGVwaWN0IHRoZXNlIHNjZW5hcmlvcyBhbmQgZ2V0DQo+IGJhY2sgdG8geW91IHdpdGgg c29tZSBzdWdnZXN0aW9ucy4NCj4gDQo+IC1SaWNoYXJkDQo= From nobody Tue Jun 19 23:43: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 4450F131053 for ; Tue, 19 Jun 2018 23:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuW1lQwyv9jO for ; Tue, 19 Jun 2018 23:43:05 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4157B131052 for ; Tue, 19 Jun 2018 23:43:05 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id BC36E1210F5; Wed, 20 Jun 2018 08:43:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 9C574180062; Wed, 20 Jun 2018 08:43:03 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0399.000; Wed, 20 Jun 2018 08:43:03 +0200 From: To: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Thread-Index: AQHUB8JBQQ8cklJ+v0SPRBhb5ILIpaRoq2pg Date: Wed, 20 Jun 2018 06:43:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF49072@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF472EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9EC7B973-66F6-4F02-AD41-43B361C551CC@consulintel.es> In-Reply-To: <9EC7B973-66F6-4F02-AD41-43B361C551CC@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 06:43:09 -0000 SGkgSm9yZGksIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKT1JESSBQQUxFVCBNQVJUSU5FWiBb bWFpbHRvOmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDE5 IGp1aW4gMjAxOCAxMzo0MA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+IENj wqA6IHY2b3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTAzLnR4dA0KPiANCj4gSGkgTWVkLA0K PiANCj4gDQo+IA0KPiBSZXNwb25kaW5nIGJlbG93LCBpbi1saW5lLg0KPiANCj4gDQo+IA0KPiBS ZWdhcmRzLA0KPiANCj4gSm9yZGkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IO+7vy0t LS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IA0KPiBEZTogPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+DQo+IA0KPiBGZWNoYTogbWFydGVzLCAxOSBkZSBqdW5pbyBkZSAyMDE4LCA3OjQx DQo+IA0KPiBQYXJhOiBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50 ZWwuZXM+DQo+IA0KPiBDQzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+DQo+IA0K PiBBc3VudG86IFJFOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNp dGlvbi1pcHY0YWFzLTAzLnR4dA0KPiANCj4gDQo+IA0KPiAgICAgSGkgSm9yZGksDQo+IA0KPiAN Cj4gDQo+ICAgICBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IA0KPiANCj4gICAgIENoZWVycywN Cj4gDQo+ICAgICBNZWQNCj4gDQo+IA0KPiANCj4gICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IA0KPiAgICAgPiBEZSA6IEpPUkRJIFBBTEVUIE1BUlRJTkVaIFttYWlsdG86am9y ZGkucGFsZXRAY29uc3VsaW50ZWwuZXNdDQo+IA0KPiAgICAgPiBFbnZvecOpIDogbHVuZGkgMTgg anVpbiAyMDE4IDE5OjA1DQo+IA0KPiAgICAgPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE4NCj4gDQo+ICAgICA+IENjIDogdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICA+IE9iamV0IDog UmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRh YXMtDQo+IDAzLnR4dA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IEhpIE1lZCwNCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFRoYW5rcyBhIGxvdCBm b3IgeW91ciBpbnB1dHMuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiBJJ3ZlIGZldyBjb21tZW50czoNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAx KSBUaGUgcmVxdWlyZW1lbnRzIGxhbmd1YWdlIGlzIHRoZSBzYW1lIGFzIGl0IHdhcyB1c2VkIGlu IFJGQzcwODQuIFdlDQo+IA0KPiAgICAgPiBiZWxpZXZlIGl0IG1ha2VzIGEgbG90IG9mIHNlbnNl IHRvIGZvbGxvdyB0aGF0Lg0KPiANCj4gICAgID4NCj4gDQo+IA0KPiANCj4gICAgIFtNZWRdIE15 IGNvbW1lbnQgd2FzIGFib3V0ICJVbmxpa2Ugb3RoZXIgSUVURiBkb2N1bWVudHMsIi4gQXMgeW91 DQo+IG1lbnRpb25lZCwgdGhlIGNvcmUgdGV4dCBpcyBhbHNvIGluIDcwODQgd2hpY2ggaXMgYW4g SUVURiBkb2N1bWVudCEgUGxlYXNlDQo+IGNvbnNpZGVyIGRlbGV0aW5nIHRoYXQgbWVudGlvbi4N Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiBJIHNlZSBub3cgd2hhdCB5b3UgbWVhbi4gS2VlcGluZyBv bmx5Og0KPiANCj4gDQo+IA0KPiAxLjEuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLSBTcGVjaWFs IE5vdGUNCj4gDQo+IA0KPiANCj4gICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs DQo+IA0KPiAgICAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwNCj4gDQo+ICAgICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzIGRvY3VtZW50IGFyZSBub3QgdXNlZCBhcw0KPiANCj4gICAgZGVzY3JpYmVkIGlu IFJGQyAyMTE5IFtSRkMyMTE5XS4gIFRoaXMgZG9jdW1lbnQgdXNlcyB0aGVzZSBrZXl3b3Jkcw0K PiANCj4gICAgbm90IHN0cmljdGx5IGZvciB0aGUgcHVycG9zZSBvZiBpbnRlcm9wZXJhYmlsaXR5 LCBidXQgcmF0aGVyIGZvciB0aGUNCj4gDQo+ICAgIHB1cnBvc2Ugb2YgZXN0YWJsaXNoaW5nIGlu ZHVzdHJ5LWNvbW1vbiBiYXNlbGluZSBmdW5jdGlvbmFsaXR5LiAgQXMNCj4gDQo+ICAgIHN1Y2gs IHRoZSBkb2N1bWVudCBwb2ludHMgdG8gc2V2ZXJhbCBvdGhlciBzcGVjaWZpY2F0aW9ucyB0byBw cm92aWRlDQo+IA0KPiAgICBhZGRpdGlvbmFsIGd1aWRhbmNlIHRvIGltcGxlbWVudGVycyByZWdh cmRpbmcgYW55IHByb3RvY29sDQo+IA0KPiAgICBpbXBsZW1lbnRhdGlvbiByZXF1aXJlZCB0byBw cm9kdWNlIGEgc3VjY2Vzc2Z1bCBJUHY2IFRyYW5zaXRpb24gQ0UNCj4gDQo+ICAgIFJvdXRlciB0 aGF0IGludGVyb3BlcmF0ZXMgc3VjY2Vzc2Z1bGx5IHdpdGggYSBwYXJ0aWN1bGFyIHN1YnNldCBv Zg0KPiANCj4gICAgY3VycmVudGx5IGRlcGxveWluZyBhbmQgcGxhbm5lZCBjb21tb24gSVB2Ni1v bmx5IGFjY2VzcyBuZXR3b3Jrcy4NCj4gDQo+IA0KPiANCj4gSSd2ZSBhbHNvIGFkZGVkIChmcm9t IFJGQzYwOTIpOg0KPiANCj4gDQo+IA0KPiAgICBBZGRpdGlvbmFsbHksIHRoZSBrZXkgd29yZCAi REVGQVVMVCIgaXMgdG8gYmUgaW50ZXJwcmV0ZWQgaW4gdGhpcw0KPiANCj4gICAgZG9jdW1lbnQg YXMgcGVydGFpbmluZyB0byBhIGNvbmZpZ3VyYXRpb24gYXMgYXBwbGllZCBieSBhIHZlbmRvciwN Cj4gDQo+ICAgIHByaW9yIHRvIHRoZSBhZG1pbmlzdHJhdG9yIGNoYW5naW5nIGl0IGZvciBpdHMg aW5pdGlhbCBhY3RpdmF0aW9uLg0KPiANCj4gDQo+IA0KPiBBbmQgY2hhbmdlZCBpbiB0aGUgZG9j dW1lbnQgYSBjb3VwbGUgb2YgdXNhZ2VzIG9mIGRlZmF1bHQgdG8gREVGQVVMVCwgc28gaXQNCj4g aXMgbW9yZSAidmlzaWJsZSIuDQo+IA0KPiANCg0KW01lZF0gT0suIA0KDQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+IDIpIFNvbWUgb2YgdGhlIGNvbW1lbnRzIGFyZSByZWxh dGVkIHRvIHRoZSB1c2FnZSBvZiBleHByZXNzaW9ucyBzdWNoIGFzDQo+IA0KPiAgICAgPiBzZXJ2 aWNlcyB2cyBzZXJ2ZXJzLCB0cmFuc2l0aW9uIHZzIHNlcnZpY2UgY29udGludWl0eSwgZXRjLiBU aGUgYXV0aG9ycw0KPiANCj4gICAgID4gY29uc2lkZXIgdGhhdCBpdCBpcyBnb29kIHRvIHVzZSB0 aG9zZSBpbnRlcmNoYW5nZWFibGUgd29yZGluZ3MsIGJlY2F1c2UNCj4gZm9yDQo+IA0KPiAgICAg PiBleGFtcGxlLCBpZiB3ZSBkb24ndCBtZW50aW9uIHRyYW5zaXRpb24sIGEgcmVhZGVyIG1heSBi ZSBjb25mdXNlZA0KPiANCj4gICAgID4gdW5kZXJzdGFuZGluZyB0aGF0IHRoaXMgaXMgbm90IHJl Z2FyZGluZyB0cmFuc2l0aW9uIGJ1dCBhIG5ldyBwcm9ibGVtDQo+IA0KPiAgICAgPiAic2Vydmlj ZSBjb250aW51aXR5Ii4gQW55d2F5LCB3ZSB3aWxsIHRha2UgYSBsb29rIGFnYWluIGludG8gdGhp cywgYW5kDQo+IGFsc28NCj4gDQo+ICAgICA+IHNlZWsgZm9yIG90aGVyIGNvbW1lbnRzIGZyb20g dGhlIFdHLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4gMykgV2lsbCBjbGFyaWZ5IGFueXRoaW5nIHRoYXQgZG9lc24ndCBwYXJzZSBlYXNpbHkgZnJv bSB5b3VyIGlucHV0cy4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+IDQpIFlvdSdyZSByaWdodCByZWdhcmRpbmcgdGhlIG51bWJlcmluZyBvZiBuZXcg R2VuZXJhbCBhbmQgTEFODQo+IHJlcXVpcmVtZW50cywNCj4gDQo+ICAgICA+IHRoZXJlIGlzIG5v IHJlYXNvbiBub3cgdG8gZm9sbG93IHRoZSBudW1iZXJpbmcgb2YgUkZDNzA4NCwgd2Ugd2lsbA0K PiBzdGFydCBmcm9tDQo+IA0KPiAgICAgPiAxLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gNSkgV2UgYmVsaWV2ZSB0aGF0IGl0IG1ha2VzIHNlbnNl IHRoYXQgaW4gdGhlIERFRkFVTFQgY29uZmlnLCBhY2NvcmRpbmcNCj4gd2l0aA0KPiANCj4gICAg ID4gdGhlIGRpc2N1c3Npb24gaW4gdGhlIGxpc3QsIHRyYW5zaXRpb24gaXMgZGlzYWJsZWQsIHNv IHdlIGF2b2lkDQo+IHBvc3NpYmxlDQo+IA0KPiAgICAgPiBjb25mbGljdHMsIHVubGVzcyB0aGUg SVNQIHR1cm5zIGl0IG9uIChmb2xsb3dpbmcgUkZDODAyNikgb3IgdGhlIHVzZXINCj4gKGJ5DQo+ IA0KPiAgICAgPiBtZWFucyBvZiBHVUkgb3IgQ0xJKS4NCj4gDQo+IA0KPiANCj4gICAgIFtNZWRd IFJGQzgwMjYgYXNzdW1lcyB0aGF0IGNvcnJlc3BvbmRpbmcgb3B0aW9ucyBhcmUgcmVxdWVzdGVk LiBJZiBhDQo+IG1lY2hhbmlzbSBpcyBkaXNhYmxlZCwgSSBhc3N1bWUgdGhlIGNvcnJlc3BvbmRp bmcgREhDUCBvcHRpb24gd29uJ3QgYmUNCj4gaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3QgdG8gdGhl IHNlcnZlci4gVFJBTlMtMSBpcyBwcm9ibGVtYXRpYy4NCj4gDQo+IA0KPiANCj4gICAgIEkgc3Rp bGwgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IuDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gT2ssIEkgdW5kZXJzdGFuZCBub3cgeW91ciBwb2ludCBhbmQgSSBiZWxpZXZlIHdl IGhhdmUgYm90aCBpbiBtaW5kIHRoZSBzYW1lDQo+IGJlaGF2aW9yLCBidXQgdGhlIHRleHQgaXMg bm90IGNsZWFyLg0KPiANCj4gDQo+IA0KPiBXaGF0IHdlIHdhbnQgaXMgdGhhdDoNCj4gDQo+IDEp IFRoZSBjb3JyZXNwb25kaW5nIG9wdGlvbnMgZm9yIGVhY2ggc3VwcG9ydGVkIHRyYW5zaXRpb24g bWVjaGFuaXNtIGFyZQ0KPiByZXF1ZXN0ZWQuDQo+IA0KPiAyKSBIb3dldmVyLCB0aGUgbWVjaGFu aXNtIGlzIERJU0FCTEVEIGF0IHRoZSB0aW1lIGJlaW5nIChubyBwYWNrZXRzIGZvcndhcmRlZA0K PiB5ZXQsIG5vIHJvdXRpbmcgZW50cmllcywgZXRjLikuDQoNCltNZWRdIEkgd291bGQgb21pdCB0 aGlzIHN0ZXAgYmVjYXVzZSB0aGlzIGlzIHRoZSBqb2Igb2YgODAyNi4NCg0KPiANCj4gMykgVW50 aWwgdGhlIFJGQzgwMjYgbWVjaGFuaXNtcyBkZWNpZGVzIHdoaWNoIG9uZXMgc2hvdWxkIGJlIGFj dHVhbGx5DQo+IEVOQUJMRUQuDQo+IA0KPiA0KSBUaGVuIHRoZSBDRSBFTkFCTEUgdGhvc2UgKGFu ZCBjb25maWd1cmVzIHJvdXRpbmcsIHN0YXJ0cyBmb3J3YXJkaW5nLA0KPiBldGMuKS4NCj4gDQo+ IA0KPiANCj4gQXQgdGhpcyB3YXksIGlmIHRoZSBJU1AgZG9lc24ndCBzdXBwb3J0ICphbnkqIG9y IGRvbid0IHdhbnQgdGhlIENFIHRvIGVuYWJsZQ0KPiBhbnksIHdpbGwgYmUgYWJsZSB0byBkbyBp dC4NCj4gDQo+IA0KPiANCj4gU28sIGFuIGFsdGVybmF0aXZlIHdvcmRpbmcgdG8gY2xhcmlmeSB0 aGlzOg0KPiANCj4gDQo+IA0KPiBUUkFOUy0xOiAgQWxsIHRoZSBzdXBwb3J0ZWQgdHJhbnNpdGlv biBtZWNoYW5pc21zIE1VU1QgYmUgY29uZmlndXJlZCBieQ0KPiANCj4gICAgICAgICAgICAgICBE RUZBVUxUIGJ5IHRoZSBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIHZpYSB0aGUgcmVsZXZhbnQN Cj4gb3B0aW9ucw0KPiANCj4gCWZvciBlYWNoIG9uZSwgaG93ZXZlciB0aGV5IE1VU1QgYmUgZGlz YWJsZWQgdW50aWwNCj4gDQo+IAlieSBtZWFucyBvZiBUUkFOUy00LCBkZWNpZGVzIHdoaWNoIG9u ZXMgYXJlIGVuYWJsZWQvZGlzYWJsZWQuDQo+IA0KPiANCg0KW01lZF0gV2h5IG5vdCBzaW1wbHkg c2F5aW5nOiBUaGUgQ0UgTVVTVCByZXF1ZXN0IHRoZSByZWxldmFudCBjb25maWd1cmF0aW9uIG9w dGlvbiBmb3IgZWFjaCBvZiBzdXBwb3J0ZWQgbWVjaGFuaXNtLiANCg0KPiANCj4gYW5kDQo+IA0K PiANCj4gDQo+IFRSQU5TLTQ6ICBUaGUgSVB2NiBUcmFuc2l0aW9uIENFIFJvdXRlciwgZm9sbG93 aW5nIFNlY3Rpb24gMS40IG9mDQo+IA0KPiAgICAgICAgICAgICAgW1JGQzgwMjZdLCBNVVNUIGNo ZWNrIGZvciBhIHZhbGlkIG1hdGNoIGluDQo+IA0KPiAgICAgICAgICAgICAgT1BUSU9OX1M0Nl9Q UklPUklUWSwgd2hpY2ggd2lsbCBhbGxvdyBlbmFibGluZy9kaXNhYmxpbmcNCj4gDQo+IAllYWNo IHRyYW5zaXRpb24gbWVjaGFuaXNtLg0KPiANCg0KW01lZF0gT0suDQoNCj4gDQo+IA0KPiBBbHNv LCBtYXliZSBpcyBiZXR0ZXIgdG8gY2hhbmdlIHRoZSBvcmRlciBvZiB0aGUgVFJBTlMgcmVxdWly ZW1lbnRzIHNvIHRob3NlDQo+IHR3byBhcmUgZm9sbG93aW5nIGVhY2ggb3RoZXIuDQo+IA0KDQpb TWVkXSBJIHdvdWxkIHVzZSB0aGlzIG9yZGVyOiBUUkFOUy0zLCBUUkFOUy0xLCB0aGVuIFRSQU5T LTQuDQoNCj4gDQo+IA0KPiANCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+IDYpIFRoZSBjb2RlIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2FzIHJlcXVl c3RlZCBpbiB2Nm9wcyB0byBiZSBrZWVwIGFzDQo+IHBhcnQNCj4gDQo+ICAgICA+IG9mIHRoZSBk b2N1bWVudCwgbm90IGFuIGFubmV4LiBXZSBhcmUgaGFwcHkgdG8gY2hhbmdlIHRoYXQgYWdhaW4g aWYNCj4gdGhhdCdzDQo+IA0KPiAgICAgPiB0aGUgV0cgZGVjaXNpb24uDQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiBXZSB3aWxsIHdhaXQgYSBmZXcg ZXh0cmEgZGF5cyBmb3IgYW55IGZ1cnRoZXIgaW5wdXRzIGJlZm9yZSBzdWJtaXR0aW5nDQo+IGEg bmV3DQo+IA0KPiAgICAgPiB2ZXJzaW9uIChiZWZvcmUgdGhlIGN1dC1vZmYpLg0KPiANCj4gICAg ID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gVGhhbmtzICENCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFJlZ2FyZHMsDQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gSm9yZGkNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4g bm9tYnJlIGRlDQo+IA0KPiAgICAgPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiBGZWNoYTogbHVuZXMsIDE4IGRlIGp1bmlvIGRlIDIwMTgs IDE0OjI3DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gUGFyYTogSk9SREkgUEFMRVQgTUFSVElO RVoNCj4gPGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gQ0M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3Jn Pg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IEFzdW50bzogUmU6IFt2Nm9wc10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtDQo+IDAzLnR4dA0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIEhpIEpvcmRp LA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg IEZXSVcsIHBsZWFzZSBmaW5kIHNvbWUgY29tbWVudHMgdG8gdGhpcyBkcmFmdCBhdDoNCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBwZGY6IGh0 dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMtDQo+IFJldmlld3MvYmxvYi9t YXN0ZXIvZHJhZnQtDQo+IA0KPiAgICAgPiBpZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0w My1yZXYlMjBNZWQucGRmDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIGRvYzogaHR0cHM6 Ly9naXRodWIuY29tL2JvdWNhZGFpci9JRVRGLURyYWZ0cy0NCj4gUmV2aWV3cy9yYXcvbWFzdGVy L2RyYWZ0LQ0KPiANCj4gICAgID4gaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDMtcmV2 JTIwTWVkLmRvYw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgIENoZWVycywNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgTWVkDQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBE ZSA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBK T1JESQ0KPiBQQUxFVA0KPiANCj4gICAgID4gTUFSVElORVoNCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgPiBFbnZvecOpIDogc2FtZWRpIDE2IGp1aW4gMjAxOCAwODo1Nw0KPiANCj4gICAg ID4NCj4gDQo+ICAgICA+ICAgICA+IMOAIDogdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiAgICAgPiBPYmpldCA6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFhcy0NCj4gDQo+ICAgICA+IDAzLnR4dA0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg ID4gSGkgYWxsLA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICA+IEFzIGluZGljYXRlZCBhIGNvdXBsZSBvZiBkYXkgYWdv LCB3ZSBoYXZlIHVwZGF0ZWQgdGhpcyBkb2N1bWVudCwNCj4gc28NCj4gDQo+ICAgICA+IGluc3Rl YWQNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBvZiBhbiB1cGRhdGUgb2YgUkZDODAy NiBhbmQgYSBuZXcgb3B0aW9uIGNvZGUsIHdlIG9ubHkgbmVlZCB0bw0KPiBhc2sgSUFOQQ0KPiAN Cj4gICAgID4gdG8NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiB1c2UgYSBOQVQ2NCBl eGlzdGluZyBvbmUgZm9yIHRoZSBSRkM4MDI2IHByaW9yaXR5IHRhYmxlLg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNp dGlvbi0NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBpcHY0YWFzLz9pbmNsdWRlX3Rl eHQ9MQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+IExldCdzIGtub3cgYW55IGNvbW1lbnRzIHlvdSBoYXZlLg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg ID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+ICAgICA+IFRoYW5rcyENCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBSZWdhcmRzLA0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gSm9yZGkNCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAg ICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICA+IO+7vy0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAg ICAgPiBEZTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSA8aW50 ZXJuZXQtDQo+IA0KPiAgICAgPiBkcmFmdHNAaWV0Zi5vcmc+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBGZWNoYTogc8OhYmFk bywgMTYgZGUganVuaW8gZGUgMjAxOCwgODo0Mw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAg ICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gUGFyYTogPGktZC1hbm5vdW5jZUBp ZXRmLm9yZz4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICA+IENDOiA8djZvcHNAaWV0Zi5vcmc+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBBc3VudG86IFt2Nm9w c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtDQo+IDAz LnR4dA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtDQo+IERyYWZ0cw0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+IGRpcmVjdG9yaWVzLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gICAgIFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXRyBvZiB0aGUNCj4gSUVURi4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAg ICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgPiAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9y IElQdjYgQ3VzdG9tZXIgRWRnZQ0KPiANCj4gICAgID4gUm91dGVycyB0bw0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+IFN1cHBvcnQgSVB2NCBDb25uZWN0aXZpdHkgYXMtYS1TZXJ2aWNl DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgPiAgICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBKb3JkaSBQYWxldCBNYXJ0aW5l eg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4gICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGFucyBNLi1ILiBMaXUNCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAg ICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hc2Fub2J1IEthd2FzaGltYQ0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg ID4gICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2 NGFhcy0NCj4gMDMudHh0DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgCVBhZ2VzICAgICAgICAgICA6IDIwDQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAg ICAgCURhdGUgICAgICAgICAgICA6IDIwMTgtMDYtMTUNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgQWJzdHJh Y3Q6DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgPiAgICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIElQdjQgc2Vydmlj ZSBjb250aW51aXR5DQo+IHJlcXVpcmVtZW50cw0KPiANCj4gICAgID4gZm9yDQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAg ICAgYW4gSVB2NiBDdXN0b21lciBFZGdlIChDRSkgcm91dGVyLCBlaXRoZXIgcHJvdmlkZWQgYnkg dGhlDQo+IA0KPiAgICAgPiBzZXJ2aWNlDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgICAgcHJvdmlkZXIgb3IgdGhydSB0 aGUgcmV0YWlsIG1hcmtldC4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgICAgU3BlY2lmaWNhbGx5LCB0aGlz IGRvY3VtZW50IGV4dGVuZHMgdGhlICJCYXNpYw0KPiBSZXF1aXJlbWVudHMgZm9yDQo+IA0KPiAg ICAgPiBJUHY2DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiAgICAgPiAgICAgICAgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzIiBpbiBvcmRlciB0 byBhbGxvdyB0aGUgcHJvdmlzaW9uaW5nDQo+IG9mDQo+IA0KPiAgICAgPiBJUHY2DQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAg ICAgICAgdHJhbnNpdGlvbiBzZXJ2aWNlcyBmb3IgdGhlIHN1cHBvcnQgb2YgIklQdjQgYXMtYS1T ZXJ2aWNlIg0KPiANCj4gICAgID4gKElQdjRhYVMpDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4g ICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgICAgYnkgbWVhbnMgb2Yg bmV3IHRyYW5zaXRpb24gbWVjaGFuaXNtcy4gIFRoZSBkb2N1bWVudCBvbmx5DQo+IGNvdmVycw0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4g ICAgID4gICAgICAgIHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIGZvciBkZWxpdmVyaW5nIElQdjQg aW4gSVB2Ni1vbmx5DQo+IGFjY2Vzcw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gICAgICAgIG5ldHdvcmtzLCBjb21tb25seSBj YWxsZWQgIklQdjQgYXMtYS1TZXJ2aWNlIiAoSVB2NGFhUyksDQo+IGFzDQo+IA0KPiAgICAgPiBy ZXF1aXJlZA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgID4gICAgICAgIGluIGEgd29ybGQgd2hlcmUgSVB2NCBhZGRyZXNzZXMgYXJl IG5vIGxvbmdlciBhdmFpbGFibGUsDQo+IHNvDQo+IA0KPiAgICAgPiBob3N0cyBpbg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4g ICAgICAgIHRoZSBjdXN0b21lciBMQU5zIHdpdGggSVB2NC1vbmx5IG9yIElQdjYtb25seSBhcHBs aWNhdGlvbnMNCj4gb3INCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAg ID4NCj4gDQo+ICAgICA+ICAgICA+ICAgICAgICBkZXZpY2VzLCByZXF1aXJpbmcgdG8gY29tbXVu aWNhdGUgd2l0aCBJUHY0LW9ubHkgc2VydmljZXMNCj4gYXQgdGhlDQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgICAgSW50 ZXJuZXQsIGFyZSBzdGlsbCBhYmxlIHRvIGRvIHNvLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAg VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAg PiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy10 cmFuc2l0aW9uLQ0KPiANCj4gICAgID4gaXB2NGFhcy8NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IGlw djRhYXMtMDMNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICA+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtdjZvcHMtDQo+IHRyYW5zaXRpb24tDQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4gICAgID4gaXB2NGFhcy0wMw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAg Pg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ICAgICBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4g ICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtDQo+IHRyYW5zaXRpb24tDQo+IA0K PiAgICAgPiBpcHY0YWFzLTAzDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ICAgICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUNCj4gdGltZSBvZg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IHN1Ym1pc3Npb24NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ICAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IA0KPiAg ICAgPiB0b29scy5pZXRmLm9yZy4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg ID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gICAgIGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAg ID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiAgICAgdjZvcHMgbWFp bGluZyBsaXN0DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiAgICAgPiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+ICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4g DQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+ IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IElQdjQg aXMgb3Zlcg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9y IHRoZSBuZXcgSW50ZXJuZXQgPw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IGh0dHA6 Ly93d3cuY29uc3VsaW50ZWwuZXMNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBUaGUg SVB2NiBDb21wYW55DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4NCj4gDQo+ICAgICA+ DQo+IA0KPiAgICAgPiAgICAgPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBtYXkgYmUNCj4gcHJpdmlsZWdlZCBvcg0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+ICAgICA+IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRv IGJlIGZvciB0aGUgZXhjbHVzaXZlDQo+IHVzZQ0KPiANCj4gICAgID4gb2YgdGhlDQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgID4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVy dGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkDQo+IA0KPiAgICAgPiBkaXNjbG9zdXJlLA0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4NCj4gDQo+ICAg ICA+IGlmDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gcGFydGlhbGx5LCBpbmNsdWRp bmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kDQo+IHdpbGwgYmUN Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2Zm ZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCBiZQ0KPiANCj4g ICAgID4gYXdhcmUNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiB0aGF0IGFueSBkaXNj bG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cw0KPiBv Zg0KPiANCj4gICAgID4gdGhpcw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IGluZm9y bWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcw0K PiBzdHJpY3RseQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+IHByb2hpYml0ZWQsIHdp bGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0DQo+IHJlcGx5 IHRvDQo+IA0KPiAgICAgPiB0aGUNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBvcmln aW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRl IGl0Lg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgID4gdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ ICAgICA+DQo+IA0KPiAgICAgPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4gICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICB2 Nm9wc0BpZXRmLm9yZw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ IA0KPiAgICAgPiBJUHY0IGlzIG92ZXINCj4gDQo+ICAgICA+IEFyZSB5b3UgcmVhZHkgZm9yIHRo ZSBuZXcgSW50ZXJuZXQgPw0KPiANCj4gICAgID4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcw0K PiANCj4gICAgID4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFRo aXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBw cml2aWxlZ2VkIG9yDQo+IA0KPiAgICAgPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBp cyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2UNCj4gb2YgdGhlDQo+IA0KPiAg ICAgPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5 IGF1dGhvcml6ZWQNCj4gZGlzY2xvc3VyZSwNCj4gDQo+ICAgICA+IGNvcHlpbmcsIGRpc3RyaWJ1 dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4NCj4g aWYNCj4gDQo+ICAgICA+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlDQo+IA0KPiAgICAgPiBjb25zaWRlcmVkIGEg Y3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBi ZQ0KPiBhd2FyZQ0KPiANCj4gICAgID4gdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlz dHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YNCj4gdGhpcw0KPiANCj4gICAgID4g aW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMs IGlzIHN0cmljdGx5DQo+IA0KPiAgICAgPiBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQg YSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0bw0KPiB0aGUNCj4gDQo+ICAg ICA+IG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFu ZCBkZWxldGUgaXQuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVy bmV0ID8NCj4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcw0KPiBUaGUgSVB2NiBDb21wYW55DQo+ IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBt YXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp bnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwo cykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNj bG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlDQo+IGNvbnNpZGVy ZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGJlIGF3YXJlDQo+IHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlv biBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMNCj4gaW5mb3JtYXRpb24sIGV2ZW4gaWYg cGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5DQo+IHByb2hp Yml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0 IHJlcGx5IHRvIHRoZQ0KPiBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29t bXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4gDQoNCg== From nobody Wed Jun 20 01:15: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 E2146130DC8 for ; Wed, 20 Jun 2018 01:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeOrCnLNUQhj for ; Wed, 20 Jun 2018 01:15:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C94130DDE for ; Wed, 20 Jun 2018 01:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529482546; x=1530087346; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=q4hbKkLm8TyZqSI4Rf24aoOOmbioMOHVUhxiO9qnM6k=; b=h+u7wktGAlr77 RDbCZCW6/cChuyeDsqS5fYAk/rUXGMovMxdDzG3qMT6yYQ+GP+h3XQruOqRumk9N 6xEdZDGUUcM5cCnrcbSQEthuMu2N73by9EAPvve7yBoYa7hZNyzGElL+bP7eZ3zo 0lIRsFM+mBYSd8V94tgaY92EqTFxo4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 20 Jun 2018 10:15:46 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Jun 2018 10:15:44 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005792786.msg for ; Wed, 20 Jun 2018 10:15:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:703e:53f8:a028:4f5e X-MDHelo: [10.10.10.129] X-MDArrival-Date: Wed, 20 Jun 2018 10:15:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17091445c1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Wed, 20 Jun 2018 10:15:39 +0200 From: JORDI PALET MARTINEZ To: CC: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt References: <152913129475.6670.9390877007080250614@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF46A3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3A04793E-53C3-4AAC-A14B-347067143149@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF472EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9EC7B973-66F6-4F02-AD41-43B361C551CC@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF49072@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF49072@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:15:52 -0000 Hi Med, Thanks again! Here is what I think we are converging: TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026] (Unified IPv4-in- IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism). TRANS-2: The IPv6 Transition CE Router MUST have a GUI and/or CLI option to manually enable/disable each of the supported transition mechanisms. TRANS-3: The IPv6 Transition CE Router MUST request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step. TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which will allow enabling a transition mechanism. TRANS-5: In order to allow the service provider to disable all the transition mechanisms, the IPv6 Transition CE Router MUST NOT enable any transition mechanisms if no match is found between the priority list and the candidate list. ", which MUST remain disabled at this step" in TRANS-3 is needed to make su= re that none of them are enabled before RFC8026 rules are followed. Accordi= ng to the conversation in this list, some people was not clear that RFC8026= allows enabling or not a given transition mechanism, so this way we state = it without doubts. TRANS-5 is required because RFC8026 has a "MAY" if no match is found or the= re is an invalid option. In this case, we want to make sure that "no match"= from an ISP means "I don't want any mechanism to be turned on". Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: mi=C3=A9rcoles, 20 de junio de 2018, 8:43 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org" Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt Hi Jordi,=20 =20 Please see inline.=20 =20 Cheers, Med =20 > -----Message d'origine----- > De : JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] > Envoy=C3=A9 : mardi 19 juin 2018 13:40 > =C3=80 : BOUCADAIR Mohamed IMT/OLN > Cc : v6ops@ietf.org > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 3.txt >=20 > Hi Med, >=20 >=20 >=20 > Responding below, in-line. >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: >=20 > Fecha: martes, 19 de junio de 2018, 7:41 >=20 > Para: JORDI PALET MARTINEZ >=20 > CC: "v6ops@ietf.org" >=20 > Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 3.txt >=20 >=20 >=20 > Hi Jordi, >=20 >=20 >=20 > Please see inline. >=20 >=20 >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > > -----Message d'origine----- >=20 > > De : JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] >=20 > > Envoy=C3=A9 : lundi 18 juin 2018 19:05 >=20 > > =C3=80 : BOUCADAIR Mohamed IMT/OLN >=20 > > Cc : v6ops@ietf.org >=20 > > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv= 4aas- > 03.txt >=20 > > >=20 > > Hi Med, >=20 > > >=20 > > >=20 > > >=20 > > Thanks a lot for your inputs. >=20 > > >=20 > > >=20 > > >=20 > > I've few comments: >=20 > > >=20 > > 1) The requirements language is the same as it was used in RFC7= 084. We >=20 > > believe it makes a lot of sense to follow that. >=20 > > >=20 >=20 >=20 > [Med] My comment was about "Unlike other IETF documents,". As you > mentioned, the core text is also in 7084 which is an IETF document! P= lease > consider deleting that mention. >=20 >=20 >=20 >=20 >=20 > I see now what you mean. Keeping only: >=20 >=20 >=20 > 1.1. Requirements Language - Special Note >=20 >=20 >=20 > The key words "MUST", "MUST NOT", >=20 > "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", >=20 > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used= as >=20 > described in RFC 2119 [RFC2119]. This document uses these keyword= s >=20 > not strictly for the purpose of interoperability, but rather for t= he >=20 > purpose of establishing industry-common baseline functionality. A= s >=20 > such, the document points to several other specifications to provi= de >=20 > additional guidance to implementers regarding any protocol >=20 > implementation required to produce a successful IPv6 Transition CE >=20 > Router that interoperates successfully with a particular subset of >=20 > currently deploying and planned common IPv6-only access networks. >=20 >=20 >=20 > I've also added (from RFC6092): >=20 >=20 >=20 > Additionally, the key word "DEFAULT" is to be interpreted in this >=20 > document as pertaining to a configuration as applied by a vendor, >=20 > prior to the administrator changing it for its initial activation. >=20 >=20 >=20 > And changed in the document a couple of usages of default to DEFAULT,= so it > is more "visible". >=20 >=20 =20 [Med] OK.=20 =20 >=20 > > >=20 > > >=20 > > 2) Some of the comments are related to the usage of expressions= such as >=20 > > services vs servers, transition vs service continuity, etc. The= authors >=20 > > consider that it is good to use those interchangeable wordings,= because > for >=20 > > example, if we don't mention transition, a reader may be confus= ed >=20 > > understanding that this is not regarding transition but a new p= roblem >=20 > > "service continuity". Anyway, we will take a look again into th= is, and > also >=20 > > seek for other comments from the WG. >=20 > > >=20 > > >=20 > > >=20 > > 3) Will clarify anything that doesn't parse easily from your in= puts. >=20 > > >=20 > > >=20 > > >=20 > > 4) You're right regarding the numbering of new General and LAN > requirements, >=20 > > there is no reason now to follow the numbering of RFC7084, we w= ill > start from >=20 > > 1. >=20 > > >=20 > > >=20 > > >=20 > > 5) We believe that it makes sense that in the DEFAULT config, a= ccording > with >=20 > > the discussion in the list, transition is disabled, so we avoid > possible >=20 > > conflicts, unless the ISP turns it on (following RFC8026) or th= e user > (by >=20 > > means of GUI or CLI). >=20 >=20 >=20 > [Med] RFC8026 assumes that corresponding options are requested. I= f a > mechanism is disabled, I assume the corresponding DHCP option won't b= e > included in the request to the server. TRANS-1 is problematic. >=20 >=20 >=20 > I still don't understand the expected behavior. >=20 >=20 >=20 >=20 >=20 > Ok, I understand now your point and I believe we have both in mind th= e same > behavior, but the text is not clear. >=20 >=20 >=20 > What we want is that: >=20 > 1) The corresponding options for each supported transition mechanism = are > requested. >=20 > 2) However, the mechanism is DISABLED at the time being (no packets f= orwarded > yet, no routing entries, etc.). =20 [Med] I would omit this step because this is the job of 8026. =20 >=20 > 3) Until the RFC8026 mechanisms decides which ones should be actually > ENABLED. >=20 > 4) Then the CE ENABLE those (and configures routing, starts forwardin= g, > etc.). >=20 >=20 >=20 > At this way, if the ISP doesn't support *any* or don't want the CE to= enable > any, will be able to do it. >=20 >=20 >=20 > So, an alternative wording to clarify this: >=20 >=20 >=20 > TRANS-1: All the supported transition mechanisms MUST be configured = by >=20 > DEFAULT by the IPv6 Transition CE Router via the releva= nt > options >=20 > for each one, however they MUST be disabled until >=20 > by means of TRANS-4, decides which ones are enabled/disabled. >=20 >=20 =20 [Med] Why not simply saying: The CE MUST request the relevant configura= tion option for each of supported mechanism.=20 =20 >=20 > and >=20 >=20 >=20 > TRANS-4: The IPv6 Transition CE Router, following Section 1.4 of >=20 > [RFC8026], MUST check for a valid match in >=20 > OPTION_S46_PRIORITY, which will allow enabling/disabling >=20 > each transition mechanism. >=20 =20 [Med] OK. =20 >=20 >=20 > Also, maybe is better to change the order of the TRANS requirements s= o those > two are following each other. >=20 =20 [Med] I would use this order: TRANS-3, TRANS-1, then TRANS-4. =20 >=20 >=20 >=20 >=20 > > >=20 > > >=20 > > >=20 > > 6) The code considerations section was requested in v6ops to be= keep as > part >=20 > > of the document, not an annex. We are happy to change that agai= n if > that's >=20 > > the WG decision. >=20 > > >=20 > > >=20 > > >=20 > > We will wait a few extra days for any further inputs before sub= mitting > a new >=20 > > version (before the cut-off). >=20 > > >=20 > > >=20 > > >=20 > > Thanks ! >=20 > > >=20 > > >=20 > > >=20 > > Regards, >=20 > > >=20 > > Jordi >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > =EF=BB=BF-----Mensaje original----- >=20 > > >=20 > > De: v6ops en nombre de >=20 > > >=20 > > >=20 > > Fecha: lunes, 18 de junio de 2018, 14:27 >=20 > > >=20 > > Para: JORDI PALET MARTINEZ > >=20 > > >=20 > > CC: "v6ops@ietf.org" >=20 > > >=20 > > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv= 4aas- > 03.txt >=20 > > >=20 > > >=20 > > >=20 > > Hi Jordi, >=20 > > >=20 > > >=20 > > >=20 > > FWIW, please find some comments to this draft at: >=20 > > >=20 > > >=20 > > >=20 > > pdf: https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/draft- >=20 > > ietf-v6ops-transition-ipv4aas-03-rev%20Med.pdf >=20 > > >=20 > > doc: https://github.com/boucadair/IETF-Drafts- > Reviews/raw/master/draft- >=20 > > ietf-v6ops-transition-ipv4aas-03-rev%20Med.doc >=20 > > >=20 > > >=20 > > >=20 > > Cheers, >=20 > > >=20 > > Med >=20 > > >=20 > > >=20 > > >=20 > > > -----Message d'origine----- >=20 > > >=20 > > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de = JORDI > PALET >=20 > > MARTINEZ >=20 > > >=20 > > > Envoy=C3=A9 : samedi 16 juin 2018 08:57 >=20 > > >=20 > > > =C3=80 : v6ops@ietf.org >=20 > > >=20 > > > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transiti= on- > ipv4aas- >=20 > > 03.txt >=20 > > >=20 > > > >=20 > > >=20 > > > Hi all, >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > As indicated a couple of day ago, we have updated this do= cument, > so >=20 > > instead >=20 > > >=20 > > > of an update of RFC8026 and a new option code, we only ne= ed to > ask IANA >=20 > > to >=20 > > >=20 > > > use a NAT64 existing one for the RFC8026 priority table. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transit= ion- >=20 > > >=20 > > > ipv4aas/?include_text=3D1 >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Let's know any comments you have. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Thanks! >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Regards, >=20 > > >=20 > > > >=20 > > >=20 > > > Jordi >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > =EF=BB=BF-----Mensaje original----- >=20 > > >=20 > > > >=20 > > >=20 > > > De: v6ops en nombre de =20 > > drafts@ietf.org> >=20 > > >=20 > > > >=20 > > >=20 > > > Fecha: s=C3=A1bado, 16 de junio de 2018, 8:43 >=20 > > >=20 > > > >=20 > > >=20 > > > Para: >=20 > > >=20 > > > >=20 > > >=20 > > > CC: >=20 > > >=20 > > > >=20 > > >=20 > > > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-i= pv4aas- > 03.txt >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > A New Internet-Draft is available from the on-line In= ternet- > Drafts >=20 > > >=20 > > > directories. >=20 > > >=20 > > > >=20 > > >=20 > > > This draft is a work item of the IPv6 Operations WG o= f the > IETF. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Title : Requirements for IPv6 Custo= mer Edge >=20 > > Routers to >=20 > > >=20 > > > Support IPv4 Connectivity as-a-Service >=20 > > >=20 > > > >=20 > > >=20 > > > Authors : Jordi Palet Martinez >=20 > > >=20 > > > >=20 > > >=20 > > > Hans M.-H. Liu >=20 > > >=20 > > > >=20 > > >=20 > > > Masanobu Kawashima >=20 > > >=20 > > > >=20 > > >=20 > > > Filename : draft-ietf-v6ops-transition-ipv4aa= s- > 03.txt >=20 > > >=20 > > > >=20 > > >=20 > > > Pages : 20 >=20 > > >=20 > > > >=20 > > >=20 > > > Date : 2018-06-15 >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Abstract: >=20 > > >=20 > > > >=20 > > >=20 > > > This document specifies the IPv4 service continuit= y > requirements >=20 > > for >=20 > > >=20 > > > >=20 > > >=20 > > > an IPv6 Customer Edge (CE) router, either provided= by the >=20 > > service >=20 > > >=20 > > > >=20 > > >=20 > > > provider or thru the retail market. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Specifically, this document extends the "Basic > Requirements for >=20 > > IPv6 >=20 > > >=20 > > > >=20 > > >=20 > > > Customer Edge Routers" in order to allow the provi= sioning > of >=20 > > IPv6 >=20 > > >=20 > > > >=20 > > >=20 > > > transition services for the support of "IPv4 as-a-= Service" >=20 > > (IPv4aaS) >=20 > > >=20 > > > >=20 > > >=20 > > > by means of new transition mechanisms. The docume= nt only > covers >=20 > > >=20 > > > >=20 > > >=20 > > > transition technologies for delivering IPv4 in IPv= 6-only > access >=20 > > >=20 > > > >=20 > > >=20 > > > networks, commonly called "IPv4 as-a-Service" (IPv= 4aaS), > as >=20 > > required >=20 > > >=20 > > > >=20 > > >=20 > > > in a world where IPv4 addresses are no longer avai= lable, > so >=20 > > hosts in >=20 > > >=20 > > > >=20 > > >=20 > > > the customer LANs with IPv4-only or IPv6-only appl= ications > or >=20 > > >=20 > > > >=20 > > >=20 > > > devices, requiring to communicate with IPv4-only s= ervices > at the >=20 > > >=20 > > > >=20 > > >=20 > > > Internet, are still able to do so. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > The IETF datatracker status page for this draft is: >=20 > > >=20 > > > >=20 > > >=20 > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-tra= nsition- >=20 > > ipv4aas/ >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > There are also htmlized versions available at: >=20 > > >=20 > > > >=20 > > >=20 > > > https://tools.ietf.org/html/draft-ietf-v6ops-transiti= on- > ipv4aas-03 >=20 > > >=20 > > > >=20 > > >=20 > > > https://datatracker.ietf.org/doc/html/draft-ietf-v6op= s- > transition- >=20 > > >=20 > > > ipv4aas-03 >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > A diff from the previous version is available at: >=20 > > >=20 > > > >=20 > > >=20 > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops- > transition- >=20 > > ipv4aas-03 >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Please note that it may take a couple of minutes from= the > time of >=20 > > >=20 > > > submission >=20 > > >=20 > > > >=20 > > >=20 > > > until the htmlized version and diff are available at >=20 > > tools.ietf.org. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP a= t: >=20 > > >=20 > > > >=20 > > >=20 > > > ftp://ftp.ietf.org/internet-drafts/ >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ >=20 > > >=20 > > > >=20 > > >=20 > > > v6ops mailing list >=20 > > >=20 > > > >=20 > > >=20 > > > v6ops@ietf.org >=20 > > >=20 > > > >=20 > > >=20 > > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > ********************************************** >=20 > > >=20 > > > IPv4 is over >=20 > > >=20 > > > Are you ready for the new Internet ? >=20 > > >=20 > > > http://www.consulintel.es >=20 > > >=20 > > > The IPv6 Company >=20 > > >=20 > > > >=20 > > >=20 > > > This electronic message contains information which may be > privileged or >=20 > > >=20 > > > confidential. The information is intended to be for the e= xclusive > use >=20 > > of the >=20 > > >=20 > > > individual(s) named above and further non-explicilty auth= orized >=20 > > disclosure, >=20 > > >=20 > > > copying, distribution or use of the contents of this info= rmation, > even >=20 > > if >=20 > > >=20 > > > partially, including attached files, is strictly prohibit= ed and > will be >=20 > > >=20 > > > considered a criminal offense. If you are not the intende= d > recipient be >=20 > > aware >=20 > > >=20 > > > that any disclosure, copying, distribution or use of the = contents > of >=20 > > this >=20 > > >=20 > > > information, even if partially, including attached files,= is > strictly >=20 > > >=20 > > > prohibited, will be considered a criminal offense, so you= must > reply to >=20 > > the >=20 > > >=20 > > > original sender to inform about this communication and de= lete it. >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ >=20 > > >=20 > > > v6ops mailing list >=20 > > >=20 > > > v6ops@ietf.org >=20 > > >=20 > > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > > >=20 > > _______________________________________________ >=20 > > >=20 > > v6ops mailing list >=20 > > >=20 > > v6ops@ietf.org >=20 > > >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > ********************************************** >=20 > > IPv4 is over >=20 > > Are you ready for the new Internet ? >=20 > > http://www.consulintel.es >=20 > > The IPv6 Company >=20 > > >=20 > > This electronic message contains information which may be privi= leged or >=20 > > confidential. The information is intended to be for the exclusi= ve use > of the >=20 > > individual(s) named above and further non-explicilty authorized > disclosure, >=20 > > copying, distribution or use of the contents of this informatio= n, even > if >=20 > > partially, including attached files, is strictly prohibited and= will be >=20 > > considered a criminal offense. If you are not the intended reci= pient be > aware >=20 > > that any disclosure, copying, distribution or use of the conten= ts of > this >=20 > > information, even if partially, including attached files, is st= rictly >=20 > > prohibited, will be considered a criminal offense, so you must = reply to > the >=20 > > original sender to inform about this communication and delete i= t. >=20 > > >=20 > > >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n if > partially, including attached files, is strictly prohibited and will = be > considered a criminal offense. If you are not the intended recipient = be aware > that any disclosure, copying, distribution or use of the contents of = this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply = to the > original sender to inform about this communication and delete it. >=20 >=20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 21 06:55:44 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 292F5130E5A for ; Thu, 21 Jun 2018 06:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 wlVKWnOg9S7Q for ; Thu, 21 Jun 2018 06:55:40 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2F0130DDD for ; Thu, 21 Jun 2018 06:55:40 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id w7-v6so3306758wrn.6 for ; Thu, 21 Jun 2018 06:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PArgd4vjhxOTi9jlK9bgQKr+BKzCa/7bjRaDSObEnBY=; b=H5SaeHSMKO3FKOUUJkAPIJnHL5Hi6DhbaYQCtc03sTij8a43i8z6Gezo4McvHTS/+f Flqh1xHD7BWozpN51E1yosa30QD6OwcKjieIIWUoTTF2kvPL6eyp0348R63Yas9Z2UIj M4E13B320sZXpOW+n2bkT+stPfhW1uLna01pJJI289bscQ8eaudLuTfrTQX1CK1zqA5L bmOHdfdPbIKmE/lQCOrOotVPTc3AvXJVgkm2Yym/496OB3HUo4W+64h/tH94WAHDoagB 0BI8Yo1TNxVR8Cer4a5kUv4MG4GFfV6H4AeE5hbzD4ShqzFYxGd+uGDS8WFKH4eCYLhu d4Qg== 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=PArgd4vjhxOTi9jlK9bgQKr+BKzCa/7bjRaDSObEnBY=; b=S8zHwri3+pD3jSPIOhYBwt3gTjsue78W7teMc6WXW8d1/pSTx9VN/yUja50/y6Gzjs BZCxXufXJ3IdJwBaJO5u+k08yXmsDSwTIvB0QJVawdbA2qotIVir7oBuR6jK8polNZpM u/jKcon2Gy7PYD/H2NOK9s/cUu3+AWQKk/JZlByK2EyoDdY4WxcM6Jbt5+MU/KMAsaQ4 57jG01SKeQ9XNTaPzGUEScy/+6GdUAzM24VhjIGAZnsQz1eeAHkQ9daPSyIcm0wYnyHI F2pbaR6wc+Yxuw986Px2lTv3hjplXwsH8ZSSWdfaeKGVEQU2724BJLHJjiWHnltz5nxh aXcg== X-Gm-Message-State: APt69E1+ng+BILOQTMacMLzFhIAMbW027aRkWYcgOvXT2veHruLdsAxf nudvxZbJvbjCjGU2tW0zowNyh883lsm0e87PbA== X-Google-Smtp-Source: ADUXVKKY2AJ7DVw0dFQ15SZEklwPF+noeUvYKIWII01PWp3OR1heZHmtezWzw7z89ML1cjT1G4b2lPciWGHpSYp6Tks= X-Received: by 2002:adf:8f23:: with SMTP id p32-v6mr21324141wrb.193.1529589338542; Thu, 21 Jun 2018 06:55:38 -0700 (PDT) MIME-Version: 1.0 References: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> In-Reply-To: <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> From: Hans Liu Date: Thu, 21 Jun 2018 21:55:27 +0800 Message-ID: To: lee@asgard.org Cc: JORDI PALET MARTINEZ , V6 Ops List Content-Type: multipart/alternative; boundary="0000000000002d1854056f27455b" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:55:43 -0000 --0000000000002d1854056f27455b Content-Type: text/plain; charset="UTF-8" > > "Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so > they need whatever the home gateway provides. No transition mechanisms are > widespread in retail gateways; DS-Lite more than others. So we're waiting > to see what goes into retail gateways. > I know! I know! Working on it!! Wish I could drive internally as I used to. Meanwhile, manufacturers are asking ISP customers what they want. You keep > hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP. > I heard both, but not recently. Either ISPs gave up or they gave up on me. :-) Best regards, Hans --0000000000002d1854056f27455b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


"Or rely on the CPE" is my point. They don't have IPv6 in= the OS now, so they need whatever the home gateway provides. No transition mechanisms are widespread in retail gateways; DS-Lite more than others. So we're waiting to see what goes into retail gateways.
I know! I know!=C2=A0 Working on it!!=C2=A0 Wis= h I could drive internally as I used to.=C2=A0

Meanwhile,= manufacturers are asking ISP customers what they want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.
I heard both, but not recently.= =C2=A0 =C2=A0Either ISPs gave up or they gave up on me.=C2=A0 :-)

Best regards,
Hans=C2=A0
--0000000000002d1854056f27455b-- From nobody Thu Jun 21 07:53: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 BDA6C130EA2 for ; Thu, 21 Jun 2018 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZyCORtmU_w9 for ; Thu, 21 Jun 2018 07:53:32 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5729B130DF0 for ; Thu, 21 Jun 2018 07:53:32 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t184-v6so1248360ywg.9 for ; Thu, 21 Jun 2018 07:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iNE9HorqHx6eYifyohBb5mGQIPeIjTTtRpxDIHBnHQo=; b=mYyEMAYq4r/izpbIUvje/SAz6gBOPWCUZFLgZMQqwU66A6Q9rVEJ1gS0dSyDDtn+AB /ih0Ju7ewUJYVVEDha5dgJFtVOvrdQeKHr8zLZMOnRsr4aaSVMhCCpK6EJIDndBvCIVK 1avDWuo5669cNBSDQgYuvv+IgJYuYfagCJ3flu0AvDmZfhLQTOPzJJo4HGZmPwU/WmU8 6xCxsxz2nlBLGa5cTQUxklHyObDVjeQfDOl4NJKTXICvy1NEwliDsXIC2gbmqeVxPbWm C0nAJ+T6jkPQi/6XFYKAHO0oqBtRqX18Ech7GSVy2WCIYnOSTe0rEsVocyuq3ikDGLs6 4zUA== 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=iNE9HorqHx6eYifyohBb5mGQIPeIjTTtRpxDIHBnHQo=; b=l8twL36Hvvb9IQ02Kd32njp21E4tScnJ8RlULgSS+IqETE7/3hHz9iwqn1XuSYkHEi v1QyeyalOIIT7BYGiGcGl++ulZlBrMwi88dfoBjdRO4AZvMTnAwz2VpZR89/Db/fElfx TnZQEoGIKcfisOP6Bv2ZfFgUiPnPxpzGpwEnA0ghpek6iXGmjlZ+xz+V+dKanqQFIl9f qVEDjDN9I5KHTYAHJde9tKsmK8yawHZpmEtLfXNh3/lmbNpjzHM59ZivIcsOnGYSdRdG UNIY4kBgDqXWCEEMu3dnXWpnTv273vzOw2cy6H/Rq06Dm5b/RfHB4lXhZWtG8Ebz/i7s CviQ== X-Gm-Message-State: APt69E1oywdyip/m8m6tlV0AbPD5qKzINHXBwfBsh1xbAYopZUWif1xx 4iBVUtG4sEngmZ2aYtodG+kWI0DUr+nRue98dHo= X-Google-Smtp-Source: ADUXVKLaWRdHnjheVt4Sk6PiR7VwhT9M0xxlxndKmbUsBsQQSXcYplyBmZlayCpmf4Jzys+O9JOKKuD753QWRBx78bg= X-Received: by 2002:a81:88c5:: with SMTP id y188-v6mr12767496ywf.408.1529592810967; Thu, 21 Jun 2018 07:53:30 -0700 (PDT) MIME-Version: 1.0 References: <0F82C180-CE02-4DC1-88EE-5BB6CEC46F3C@consulintel.es> <7eb46aa1-699a-7397-d0d9-51d1160b4148@hit.bme.hu> <671083EC-62E4-44ED-91AD-EBD0DFB086F6@employees.org> <377fe961-c11c-de2d-35dd-6be8478a94b3@asgard.org> <405c3498-7159-6888-d756-f72346cb188d@asgard.org> <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> In-Reply-To: <8a4ddec8-6d43-b59d-f685-69b0295ac38b@asgard.org> From: Ca By Date: Thu, 21 Jun 2018 07:53:19 -0700 Message-ID: To: Lee Howard Cc: JORDI PALET MARTINEZ , v6ops@ietf.org Content-Type: multipart/alternative; boundary="00000000000026221d056f281477" Archived-At: Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:53:35 -0000 --00000000000026221d056f281477 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2018 at 10:34 AM Lee Howard wrote: > > > On 06/14/2018 10:20 AM, JORDI PALET MARTINEZ wrote: > > > > I recall Windows Update 10 also has included CLAT support. I=E2=80=99m su= re this > will happen more and more in different OSs, as it makes a lot of sense in > networks that may already have NAT64. > > > You think? Like game console OSs and thermostat OSs and stereo OSs and TV > OSs? > > > No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). > It makes a lot of sense specially for devices that are =E2=80=9Cportable= =E2=80=9D and in > fact that=E2=80=99s the idea behind Windows 10 Update. If you can use tha= t device > in a cellular IPv6-only network, should be expected that in a WiFi or wir= ed > IPv6-only network is behaving the same way when no native IPv4 is > available. The other kind of OSs that you mention should either have > already IPv6-only or rely in the CPE to provide IPv4 if they really need > that. > > > "Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so > they need whatever the home gateway provides. No transition mechanisms ar= e > widespread in retail gateways; DS-Lite more than others. So we're waiting > to see what goes into retail gateways. > Meanwhile, manufacturers are asking ISP customers what they want. You kee= p > hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP. > > BUT it would be cool if game consoles did deploy CLAT, and provide a > translation layer for games that only know IPv4. I don't know the > architecture well enough to know whether that would work, > > Also, tethering behind an IPv6-only phone is still no problem if you have > Windows 10 and a NAT64 server, apparently: just fire up the CLAT. > > > > That only matters if it actually gets implemented. "Easy" and "done" are > different. > > You've said that home gateway vendors by and large have code for all of > the mechanisms already written, so I'm not sure ease is essential. > > Yeah, talked to many, they often provide whatever you need if the order i= s > big, our problem is still the retail market or orders to vendors that don= =E2=80=99t > have sufficient amount to demand a specific firmware feature set. > > > > Code required for each transition in OpenWRT (it may be quite similar in > other implementations): > > > > DS-Lite 15 Kbytes > > 464XLAT 17 Kbytes > > MAP-E 35 Kbytes > > LW4o6 35 Kbytes > > MAP-T 48 Kbytes > > > > If *all* them are implemented: 53 Kbytes (there are many =E2=80=9Cshared= =E2=80=9D modules > among them, same data plane, etc.). > > > There are other drivers here, and while I have no concerns about 464xlat, > I also am not ready to crown it the winner. > > > > I bet a dinner =E2=80=A6 Cellular is too powerful and they made the decis= ion long > time ago. > > > What's the decision criterion? :) > Mobile is huge, but has little influence on wireline. And most of them > (globally) are still on dual stack. > Yes, mobile is huge. Also, i have seen 5G scenarios where pure play mobile and mobile / wireline providers are choosing to deploy home broadband with wireless 5G. If that mobile team had smashing success with 464xlat, i imagine they would keep that model for 5G home broadband products. After all, entering the home broadband market as geenfield would be silly not to be a ipv6 first service. > > Lee > > > > Lee > > > > Regarsd, > > Jordi > > > > > > > > *De: *v6ops en nombre > de Lee Howard > *Fecha: *jueves, 14 de junio de 2018, 15:16 > *Para: * > *Asunto: *Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT > really inferior to all other IPv6 transition technologies? -- Re: updatin= g > RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas > > > > > > > > On 06/14/2018 08:12 AM, Ca By wrote: > > > > > > On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti 40google.com@dmarc.ietf.org> wrote: > > On Thu, Jun 14, 2018 at 7:28 PM wrote: > > > > > > Oh, I definitely agree that 464xlat has it's place. I maintain a popular > implementation of it :-) > > > > I'm just saying it's not the best solution for a wireline network. > > > > Perhaps. > > > > The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat= . > > > > Afaik, there is not a large production stateless MAP implementation, and > this market is fairly mature. That said, at this point, the theoretical > advantage of stateless has failed to materialize in real world deployment > ... while the stateful solutions keep gaining share. > > > > > > Crowd-sourced list of transition technologies various carriers have > deployed: > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_= 7NK9vcVApc/edit#gid=3D0 > > I see several that have deployed MAP. > > I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early > development), and were the only game in town. 464xlat only has that > advantage in mobile, since handsets are the only major CLAT implementatio= n. > > I think it's too soon to declare winners. > > Lee > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000026221d056f281477 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu,= Jun 14, 2018 at 10:34 AM Lee Howard <= lee@asgard.org> wrote:



On 06/14/2018 10:20 = AM, JORDI PALET MARTINEZ wrote:
=20 =20 =20

=C2=A0

I recall Windows Update 10 also has included CLAT support. I=E2=80=99m= sure this will happen more and more in different OSs, as it makes a lot of sense in networks that may already have NAT64.


You think? Like game console OSs and thermostat OSs and stereo OSs and TV OSs?


No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It makes a lot of sense specially for devices that are =E2=80=9Cportable=E2=80=9D and in fact that=E2=80=99s the i= dea behind Windows 10 Update. If you can use that device in a cellular IPv6-only network, should be expected that in a WiFi or wired IPv6-only network is behaving the same way when no native IPv4 is available. The other kind of OSs that you mention should either have already IPv6-only or rely in the CPE to provide IPv4 if they really need that.


"Or rely on the CPE" is my point. They don't have IPv6 in= the OS now, so they need whatever the home gateway provides. No transition mechanisms are widespread in retail gateways; DS-Lite more than others. So we're waiting to see what goes into retail gateways.
Meanwhile, manufacturers are asking ISP customers what they want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.

BUT it would be cool if game consoles did deploy CLAT, and provide a translation layer for games that only know IPv4. I don't know the architecture well enough to know whether that would work,

Also, tethering behind an IPv6-only phone is still no problem if you have Windows 10 and a NAT64 server, apparently: just fire up the CLAT.



That only matters if it actually gets implemented. "Easy&quo= t; and "done" are different.

You've said that home gateway vendors by and large have code for all of the mechanisms already written, so I'm not sure ease is essential.

Yeah, talked to many, they often provide whatever you need if the order is big, our problem is still the retail market or orders to vendors that don=E2=80=99t have sufficient amount to demand a specific firmware feature set.

=C2=A0

Code required for each transition in OpenWRT (it may be quite similar in other implementations):

=C2=A0

DS-Lite=C2=A0=C2=A0 15 Kbytes<= /p>

464XLAT 17 Kbytes

MAP-E =C2=A0=C2=A0=C2=A035 Kbytes<= /u>

LW4o6 =C2=A0=C2=A035 Kbytes

MAP-T =C2=A0=C2=A048 Kbytes

=C2=A0

If *all* them are implemented: 53 Kbytes (there are many =E2=80=9Cshared=E2=80=9D= modules among them, same data plane, etc.).


There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner. <= /u>

=C2=A0

I bet a dinner =E2=80= =A6 Cellular is too powerful and they made the decision long time ago.


What's the decision criterion? :)
Mobile is huge, but has little influence on wireline. And most of them (globally) are still on dual stack.

Yes, mobile is huge.=C2=A0

Also, i have seen 5G scenarios where pure play mobile and mobile = / wireline providers are choosing to deploy home broadband with wireless 5G= .=C2=A0

If that mobile t= eam had smashing success with 464xlat, i imagine they would keep that model= for 5G home broadband products.=C2=A0 After all, entering the home broadba= nd market as geenfield would be silly not to be a ipv6 first service.=C2=A0=





Lee



Lee
=C2=A0


Regarsd,

Jordi

=C2=A0

=C2=A0

=C2=A0

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lee Howard <lee@asgard.org>
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

=C2=A0

=C2=A0

=C2=A0=

On 06/14/2018 08:12 AM, Ca By wrote:

=C2=A0=

=C2=A0=

On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=3D40google.com@dmarc.ietf.org> wrote:

On Thu, Jun 14, 2018 at 7:28 PM <nick.heatley@bt.com> wrote:

=C2=A0

=C2=A0

Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-)

=C2=A0

I'm just saying it's not the best solution for a wireline network.=C2=A0

=C2= =A0

Perha= ps.=C2=A0

=C2= =A0

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.=C2=A0

=C2= =A0

Afaik= , there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share.=C2=A0

=C2= =A0



Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4= O5L1OUTNOO_7NK9vcVApc/edit#gid=3D0

I see several that have deployed MAP.

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation.

I think it's too soon to declare winners.

Lee



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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://= www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--00000000000026221d056f281477-- From nobody Thu Jun 21 08:05: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 95E98131259 for ; Thu, 21 Jun 2018 08:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCznBmEy3h9t for ; Thu, 21 Jun 2018 08:05:25 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99ACF130EF1 for ; Thu, 21 Jun 2018 08:05:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id E6BF5FAC6DA; Thu, 21 Jun 2018 12:05:21 -0300 (ART) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RNCi9UcqGt3X; Thu, 21 Jun 2018 12:05:19 -0300 (ART) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 10CB7FAC7E5; Thu, 21 Jun 2018 12:05:19 -0300 (ART) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 10CB7FAC7E5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=AF3BF44E-65A6-11E7-AE62-64B2068F9D73; t=1529593519; bh=B5MYRprMu7UTPMMTHZVaxrrH1pr/Wni8fDzGrlGVYxQ=; h=Date:From:To:Message-ID:MIME-Version; b=ga7C2++eaNXaBOIUmjs5e+KTbVvXOpMaSwefENAiLv9YI7vTjBEmHQPxjCKQolioB ghdtIUdmmbwSBGDJoi2+KexSAOI3IUBRnfnRjsd/ZZyZ1LJSKL15RwYn7C+EkWoKKG vlEUKTuF/V6LWesNBUeB0YIZUB8wP3VfCTr0Nuqwoj6Xk7jCfTsnuWdLUMKXLF6Ar4 VdNlBBHJRmUgT9iW8Xxubwl/4rZC7Q+fd6zqZ8Tz6U/oSJeWd4quUxUQx++SfUERSM 3F8uQiR0YADRKtl+7sGSrBPhN1bXNHtRravP2Nzu3my0fWPyHzcrReQoDKxTeuaz8M ae0RkH6SiyU5g== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ja5GWPiXQg28; Thu, 21 Jun 2018 12:05:18 -0300 (ART) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id D88CAFAC7B6; Thu, 21 Jun 2018 12:05:18 -0300 (ART) Date: Thu, 21 Jun 2018 12:05:18 -0300 (ART) From: Alejandro D'Egidio To: lencse@hit.bme.hu Cc: "v6ops@ietf.org list" Message-ID: <227345651.69811748.1529593518667.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: <940CC666-9208-4784-B452-58D5482B7782@consulintel.es> <6b691c03-a2ee-3656-e1bc-edbb17583216@hit.bme.hu> <1BFAD96D-F06E-4EBF-8751-761EF08E6EE0@consulintel.es> <67b5991a-e7ac-aef2-eeae-7531598428fe@asgard.org> <211c5c27-11a3-b264-3b5a-9d8f10f6ec45@hit.bme.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - GC67 (Win)/8.7.0_GA_1659) Thread-Topic: "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas Thread-Index: qJzFgV9s7uoPqfg7bOoog/i/gX3IGw== Archived-At: Subject: Re: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:05:36 -0000 Hi Lencse, If is possible, I would like to help. Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025=C2=A0 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ----- Mensaje original ----- De: "Richard Patterson" Para: lencse@hit.bme.hu CC: "v6ops@ietf.org list" Enviados: Martes, 19 de Junio 2018 5:29:14 Asunto: Re: [v6ops] "BoF" for I-D -- Re: Pros and Cons of IPv6 Transition T= echnologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6op= s-transition-ipv4aas Hi Lencse, I'd be happy to help also. -Richard On Tue, 19 Jun 2018 at 08:09, Lencse G=C3=A1bor wrote: > > Dear Lee, > > Thank you very much for offering your help and participation. I have deci= ded to write the draft and I invite you to be a co-author. > > Are there some other people, who would like to join us? > > I plan to put together a table with the information extracted from past e= -mails on the list and send it to Lee (and possibly other participants) fir= st, and send the Google docs URL to the list after we agreed on its initial= content. > > Best regards, > > G=C3=A1bor > > > 6/18/2018 4:38 PM keltez=C3=A9ssel, Lee Howard =C3=ADrta: > > Apparently I'm a week late on this thread. Sorry. > > I think an internet-draft in this case would be useful for reflecting the= current best knowledge about the technologies. Even if it takes two years = or more to publish, a draft is useful to collect and summarize the detaile= d academic papers being published, and the structure of writing the draft w= ill help point out areas where further research is needed. > > I'm also interested in supporting this work, up to and including working = with your students, providing my own test results, and/or co-authoring. > > Lee > > > On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote: > > I=E2=80=99m not sure it makes sense something that is not published in, l= et=E2=80=99s say, maximum one year from now. > > > > Anyway, I=E2=80=99m happy to help. > > > > By the way, I got some private questions about this =E2=80=A6 The table t= hat I=E2=80=99ve posted yesterday, was developed about 3 years ago, and I= =E2=80=99ve not updated it since them. Actually from emails exchanged today= , I discovered a couple of mistakes and also things that can be improved, s= o if needed I can update it as well. > > > Regards, > > Jordi > > > > > > > > De: v6ops en nombre de Lencse G=C3=A1bor > Fecha: viernes, 15 de junio de 2018, 14:25 > Para: Fred Baker > CC: > Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS= -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas > > > > Dear Fred, > > Thank you very much for your invitation. I am willing to accept it, but I= would like to clarify your expectations before saying 'yes'. > > I have several questions. > > 1. Depth of the analysis > > - Basic level: well-known advantages and disadvantages, similarly as peop= le wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6. > - Advanced level: basic level + security analysis using the methodology d= efined in [1] + performance analysis according to RFC 8219. > > What depth do you recommend? > > 2. Method for getting the results and their publication > > As for the information for the basic level, I would prepare a google docs= table, fill in the information I have and send the link to the v6ops list = asking contributions. > After commenting and discussing, I would compile it to an I-D. > > Do you think that v6ops WG would finally agree to publish it as an RFC? > > As for the information for the advanced level, I would work together with= my students and PhD students, and publish our results first in academic pa= pers and then include their most important lessons into the I-D. > > What do you think of it? > > 3. Timeline > > I think that I could put together the first table in a few weeks. The con= tribution of the v6ops list members and the discussion could be done in a f= ew months and then I could compile the results into an I-D in a few weeks. = Perhaps, it could be presented at IETF 103. > > The further parts would require much more time and results could be inclu= ded gradually in 1-2 years. > > 4. Scope > > The smallest natural scope includes the technologies for IPv4AAS, that is= : 464XLAT, DS-Lite, MAP-T/E and lw4o6. > > IPv6 transition technologies for other carefully selected scenarios might= also be included. E.g. I have significant amount of results in benchmarkin= g DNS64 servers, having a testing tool [2], a well defined methodology [3] = and ready to use results concerning the DNS64 performance of BIND, PowerDNS= and Unbound [4]. > One of my PhD students is currently benchmarking some sateless NAT64 impl= ementations according the the dual DUT setup of RFC 8219 using an RFC 2544 = compatible Tester. Another PhD student is currently working on a RFC 8219 c= ompliant NAT64 tester program (using DPDK) to be able to perform single DUT= setup NAT64 benchmarking tests. > > Thus, the scope can be widened, if you would like to. > > What do you think about my recommendations? > > Best regards, > > G=C3=A1bor > > References: > > [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of = potential security issues of different IPv6 transition technologies: Threat= analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vo= l. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 > > [2] G. Lencse, D. Bakai, "Design and implementation of a test program for= benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E1= 00-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007 > > [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodolog= y for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, = pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004 > > [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Th= eory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp= . 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 > > 6/14/2018 10:42 PM keltez=C3=A9ssel, Fred Baker =C3=ADrta: > > > > On Jun 14, 2018, at 1:15 PM, Lencse G=C3=A1bor wrote: > > I have an idea: perhaps you could add a section about the pros and cons o= f each transition technology covered by the draft. (It could be helpful for= the network operators when selecting the technology matching their need th= e best. However, I am not sure whether it is in the scope of this draft.) > > It would be incredibly useful. That said, it often involves value judgeme= nts, which are essentially in the eye of the beholder. > > > > We have had a recent thread regarding 464xlat and MAP-T. If I can say thi= s without actually putting words into Lorenzo's mouth, his issues with tran= slation in general are probably summarized in RFC 2993, and I would agree w= ith him. The distinction between 464xlat and MAP-T you'll have to find in h= is emails; they are both services an ISP might deploy, and while they use t= he same tool (translation) they are not the same service. It seems to be ge= nerally agreed that MAP-T is more expensive to deploy than 464xlat; the que= stion is what the extra expense buys, and whether someone agrees that the r= esult is worth the cost. > > > > So in your proposed section, I would have to ask Jordi to not only say "M= AP-T costs more to deploy than 464xlat", but gives the argument that might = lead someone to choose MAP-T. > > > > And then we get to the large variety of other technologies, some of which= presume an IPv4 core network and some an IPv6 core network (and none of wh= ich assume an MPLS core network carrying both kinds of traffic). > > > > If you would like to write such a document, please be my guest, by all me= ans. But I'm not going to expect Jordi to do all that in the coming two wee= ks... > > > _______________________________________________ v6ops mailing list v6ops@= ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 21 16:41: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 270C7127AC2; Thu, 21 Jun 2018 16:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYgh43tzsEsx; Thu, 21 Jun 2018 16:41:12 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93A012785F; Thu, 21 Jun 2018 16:41:12 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5LNe2CR008610; Thu, 21 Jun 2018 16:41:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=Vj30YkrEez29bq6ok9ywkGhws2LsXL/wDJbR7gH86jQ=; b=mWs2gNXnPhG6n/pEfrWaW8ME0pUl3awCg1dg/LKC2lewo0VOQaBrDli7XKprNNWN9EfI 0WH2BEzpSJOYH3eToYCGvf3SMEwo6rjlvARHkZOOL+NzKRWS5mGmr0nbszyGJatUeSIp J1SRl7lnDlxJI8pBNsJNtkirKkdNHFQmLvVtAOG+b4pti5i6YH8ectcqKMSiCqcW6SKZ weI6KGtfPaBkbIsrjrLRJ1cZitdezyVWI0NlRzoSZTDfqEEwKaDXfeLoVkwNmZgMHkii DCcM3dTggaIioVHInXMjoAbr9TN0dqVDv7nXjdBMXOObqmt7ELaEl3MYj4WDwoteutl7 tA== Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0118.outbound.protection.outlook.com [216.32.180.118]) by mx0a-00273201.pphosted.com with ESMTP id 2jrmp18367-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Jun 2018 16:41:10 -0700 Received: from MWHPR05MB3200.namprd05.prod.outlook.com (10.173.229.143) by MWHPR05MB3470.namprd05.prod.outlook.com (10.174.248.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.16; Thu, 21 Jun 2018 23:41:08 +0000 Received: from MWHPR05MB3200.namprd05.prod.outlook.com ([fe80::158f:840b:381b:9154]) by MWHPR05MB3200.namprd05.prod.outlook.com ([fe80::158f:840b:381b:9154%2]) with mapi id 15.20.0884.010; Thu, 21 Jun 2018 23:41:08 +0000 From: Ravi Singh To: Jen Linkova CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-conditional-ras@ietf.org" Thread-Topic: [v6ops] RtgDir review: draft-ietf-v6ops-conditional-ras Thread-Index: AdPxWdYhiDZAt4tdT0u33w6T+4L0MQVhcpQAALZV2LA= Date: Thu, 21 Jun 2018 23:41:07 +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: [66.129.239.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3470; 7:2CelZFbTSJ7zXJrjm+YEcozdRB6ANwfIYPDycZZME/JWyjtc6PXbCKpCL0l3CQ4fyCAwnj8HIO4cg3ZN99Tdx1bamPKF+C46fqWFOrhnnkeFjrszYWJlyjcamyrKZhUWZBIjIULUCjzQnaPcHX6Aoij7lGMOkdVwQN3bQdyBqdTOGjG9/cpoXWftOCpuBv1ucnIU80AIMCQzKD8jep8HCcT9GQbDabheS2YS3lw9c1kOI8dVc2kUvU5CUu53vUvw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a51e9591-cf52-4055-d724-08d5d7d07642 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:MWHPR05MB3470; x-ms-traffictypediagnostic: MWHPR05MB3470: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MWHPR05MB3470; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3470; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(366004)(39380400002)(189003)(13464003)(199004)(446003)(68736007)(14454004)(966005)(6116002)(106356001)(3846002)(59450400001)(476003)(105586002)(478600001)(486006)(5250100002)(97736004)(25786009)(2900100001)(11346002)(1411001)(53546011)(4326008)(53936002)(6246003)(39060400002)(33656002)(229853002)(575784001)(99286004)(86362001)(5660300001)(7696005)(6916009)(2906002)(9686003)(6306002)(55016002)(76176011)(3660700001)(316002)(3280700002)(54906003)(102836004)(7736002)(305945005)(8676002)(74316002)(6506007)(66066001)(26005)(186003)(81156014)(81166006)(8936002)(6436002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3470; H:MWHPR05MB3200.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: +Bmc0lZzlCwa/5GqZQFaSdGjgE+QD+5uzf/x7m3IMwggpDXW8ZehjPJZiIyPaKOyH3u6duhwT2z7IkBzihsf6/2sm919wEeSNImywudP4ZkSihccHwTPjyO7o+J1BXC17lAC4946MebT8ZiDIdWm/0EHFW+cxoZ4k6v28yiQClhApPmQkfI1EKE+G+FrNIhBafLq9xDH/A8MvNxZBUv1EZhlmMlplXKDyVqWSLz+mqoKLurKvBFXz/CGc3WhUMvaTB4n7aAETgmhshOmoR0yxECrwXfuO9EKNoOxXM1J1CWw6p4CmloZ5MlyAFhqsTL2RmC7NSVyWjfIy5z13V8WOw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a51e9591-cf52-4055-d724-08d5d7d07642 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 23:41:07.9414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3470 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 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-1805220000 definitions=main-1806210256 Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 23:41:16 -0000 SGkgSmVuDQpUaGFua3MgZm9yIHlvdXIgdXBkYXRlIG9mIHRoZSBkb2MuDQpSZWdhcmRzDQpSYXZp DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKZW4gTGlua292YSBb bWFpbHRvOmZ1cnJ5MTNAZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTgsIDIwMTgg MTozOCBBTQ0KPiBUbzogUmF2aSBTaW5naCA8cmF2aXNAanVuaXBlci5uZXQ+DQo+IENjOiBydGct YWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi12Nm9wcy0NCj4gY29uZGl0aW9uYWwtcmFzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZv cHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtdjZvcHMtY29uZGl0aW9uYWwtcmFzDQo+IA0K PiBIaSBSYXZpLA0KPiANCj4gTXkgYXBvbG9naWVzIGZvciB0aGUgZGVsYXkgd2l0aCBhZGRyZXNz aW5nIGlzc3VlcyB5b3UgcmFpc2VkIGluIHlvdXIgcmV2aWV3IQ0KPiBJJ3ZlIGp1c3QgdXBsb2Fk ZWQgLTA1IHZlcnNpb24sDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0NCj4gM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYt MkR2Nm9wcy0yRGNvbmRpdGlvbmFsLQ0KPiAyRHJhc18mZD1Ed0lGYVEmYz1IQWtZdWg2M3JzdWhy NlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTZBcmtFNG4yMG1OWlFGNkp4ck1Z d0p5QUdCV1dqemhTSUMyTzMtDQo+IGZYUFY0Jm09T2h6VHVDdF9kVWVjOWxSMUE3MkRHVVB1bDVT WGdFSXhMTEwxSzlXMFdxUSZzPVNEcUlNeXYNCj4gQm9kOEdZM1hVVk5yMmh1bmE4WEx4dTRLQ1JY UmlCSG1BeFZ3JmU9DQo+IHBsZWFzZSBsZXQgbWUga25vdyBpZiBpdCBzdGlsbCBoYXMgYW55IGlz c3Vlcy4NCj4gDQo+IE9uIFR1ZSwgTWF5IDIyLCAyMDE4IGF0IDk6MjUgQU0sIFJhdmkgU2luZ2gg PHJhdmlzQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPiBEb2N1bWVudDogZHJhZnQtaWV0Zi12Nm9w cy1jb25kaXRpb25hbC1yYXMNCj4gPiBTdW1tYXJ5OiBUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxs eSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0DQo+IHNob3VsZCBiZSBj b25zaWRlcmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLg0KPiA+DQo+ID4gTml0czoNCj4gPiAgICBk LiBTZWN0aW9uIDMuMi4zOiB0eXBvOiBxdW90ZWQgc2VjdGlvbiAjIG5lZWRzIGNvcnJlY3Rpb24u DQo+ID4gICAgICAgICAgICIgY29ycmVjdCB1cGxpbmsgYmFzZWQgb24gdGhlIHNvdXJjZSBhZGRy ZXNzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uDQo+IDMuMi4xLiINCj4gPiAgICAgICAgICAgIC0+ DQo+ID4gICAgICAgICAgImNvcnJlY3QgdXBsaW5rIGJhc2VkIG9uIHRoZSBzb3VyY2UgYWRkcmVz cyBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbg0KPiAzLjEuMS4iDQo+IA0KPiBUaGUgcmVmZXJlbmNl IHdhcyBhY3R1YWxseSBjb3JyZWN0LCBJJ3ZlIHVwZGF0ZWQgdGhlIHdvcmRpbmcgdG8gbWFrZSBp dCBtb3JlDQo+IGNsZWFyLg0KPiANCj4gPiA0LiBTZWN0aW9uIDMuMyAmIDMuNDogdGhlIHRleHQg c2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIGRyYWZ0IGlmIHByb3Bvc2luZw0KPiBzb21lIHNv bHV0aW9uLCBldmVuIHRob3VnaCBhcyBpbmRpY2F0ZWQgaW4gdGhpcyBkcmFmdCdzIGFic3RyYWN0 4oCmLnRoZSBzb2x1dGlvbg0KPiBiZWluZyByZWZlcmVuY2VkIGlzIGluIGlldGYtcnRnd2ctZW50 ZXJwcmlzZS1wYS1tdWx0aWhvbWluZyBhbmQgdGhpcyBkcmFmdCBpZg0KPiBkZXNjcmliaW5nIHRo ZSB1c2Ugb2YgdGhhdCBzb2x1dGlvbiBpbiBzYW1wbGUgc2NlbmFyaW9zLiBTbGlnaHQgcmV3b3Jk aW5nIG9mIHRleHQNCj4gc2hvdWxkIGhlbHAgdG8gYWRkcmVzcyB0aGlzLg0KPiANCj4gSSd2ZSB1 cGRhdGVkIHRoZSBhYnN0cmFjdCBhbmQgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIHRvIGNsYXJp ZnkgdGhhdCB0aGlzIGRyYWZ0DQo+IHByb3ZpZGVzIGEgc29sdXRpb24gYmFzZWQgb24gdGhlIGdl bmVyYWwgYXBwcm9hY2ggZGlzY3Vzc2VkIGluIGlldGYtcnRnd2ctDQo+IGVudGVycHJpc2UtcGEt bXVsdGlob21pbmcuDQo+IA0KPiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Sat Jun 23 10:45: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 4953E13106E for ; Sat, 23 Jun 2018 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItOiB9nzDTrM for ; Sat, 23 Jun 2018 10:45:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB9213106B for ; Sat, 23 Jun 2018 10:45:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fWmap-0000IoC; Sat, 23 Jun 2018 19:44:59 +0200 Message-Id: To: v6ops@ietf.org Cc: S Moonesamy From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <152946990900.32509.15132787302635646979@ietfa.amsl.com> <50bdcf46-de26-66cd-415d-0c964fd38d57@gmail.com> <915CA4E0-D278-4BCA-B271-CC3BA8177CB8@employees.org> <864efe39-9759-d10b-1dce-27485ab743c1@gmail.com> <9873CDF0-8415-4B9E-8854-5D207BB2FF37@employees.org> <27a0b169b8774ada8558f1c1606ad8fe@XCH15-01-07.nw.nos.boeing.com> <6.2.5.6.2.20180623052647.0c968b90@elandnews.com> In-reply-to: Your message of "Sat, 23 Jun 2018 05:38:30 -0700 ." <6.2.5.6.2.20180623052647.0c968b90@elandnews.com> Date: Sat, 23 Jun 2018 19:44:48 +0200 Archived-At: Subject: Re: [v6ops] SAILing LAPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 17:45:20 -0000 >There was a discussion about recommendations of the IETF about IPv6 >address assignments and it ended with a RFC 6177. I suggest reading >the summary of that discussion (in Section 5). Unfortunately, RFC 6177 contains exactly the worrying arguements that should encourage drawing a line in the sand and keeping the 64 bit boundary. The IETF had clear technical ideas why customers should get a /48. It is possible that the IETF mis-understood operational concerns. However, RFC 6177 does not discuss clear operational problems with /48. Instead we get the following text: "While the /48 recommendation does simplify address space management "for end sites, it has also been widely criticized as being wasteful. "For example, a large business (which may have thousands of employees) "would, by default, receive the same amount of address space as a home "user, who today typically has a single (or small number of) LAN and a "small number of devices (dozens or less). It is clear that operators consider bits to precious without any operational reason behind that. What are the benefits of providing customers with longer prefixes? We don't know. So reality is that operators cannot know what a customer really needs. They have some model of what a customer should need according to them, and the possibility to upsell. So instead of having clear guide lines that customers need to get a /48, we now have a discussion on subdividing /64s. From nobody Sat Jun 23 10:48:09 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 8F09513106E for ; Sat, 23 Jun 2018 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c0mjqAT1y9v for ; Sat, 23 Jun 2018 10:48:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0083C13106B for ; Sat, 23 Jun 2018 10:48:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fWmdo-0000FrC; Sat, 23 Jun 2018 19:48:04 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <152946990900.32509.15132787302635646979@ietfa.amsl.com> <50bdcf46-de26-66cd-415d-0c964fd38d57@gmail.com> <915CA4E0-D278-4BCA-B271-CC3BA8177CB8@employees.org> <864efe39-9759-d10b-1dce-27485ab743c1@gmail.com> <9873CDF0-8415-4B9E-8854-5D207BB2FF37@employees.org> <27a0b169b8774ada8558f1c1606ad8fe@XCH15-01-07.nw.nos.boeing.com> <6.2.5.6.2.20180623052647.0c968b90@elandnews.com> In-reply-to: Your message of "Sat, 23 Jun 2018 19:44:48 +0200 ." Date: Sat, 23 Jun 2018 19:48:04 +0200 Archived-At: Subject: Re: [v6ops] SAILing LAPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 17:48:08 -0000 Oops, this was meant to go to 6man. From nobody Sat Jun 23 11:27: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 BF42513108F for ; Sat, 23 Jun 2018 11:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73QhqQoW7-6k for ; Sat, 23 Jun 2018 11:27:12 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A48131084 for ; Sat, 23 Jun 2018 11:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529778428; x=1530383228; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=3pH+Tf38HxhtD9+mHclmkuIAz+7J3klixm2M6c5wo+I=; b=CFQM9YAhHdjL8 WNlQKK7PyOT9qU8RVeIKCCCcuJ2yX+LoavfZKvO4tDclz2TyLT2RmY7I4trLRQVj AiY5rF64g/lnoFWK9ldkfg+2mO9CzIlAsxLt5r7LKpc12LweztEDc5HFdR4Kj+Pf 1eyeyt2BXM4XiLrJgBiKCFrZoR5UsU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 23 Jun 2018 20:27:08 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 23 Jun 2018 20:27:07 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005794803.msg for ; Sat, 23 Jun 2018 20:27:06 +0200 X-MDRemoteIP: 2001:470:1f09:495:9813:4fa4:7a06:85a4 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sat, 23 Jun 2018 20:27:06 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1712d3905e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Sat, 23 Jun 2018 20:27:02 +0200 From: JORDI PALET MARTINEZ To: Philip Homburg , CC: S Moonesamy Message-ID: Thread-Topic: [v6ops] SAILing LAPs References: <152946990900.32509.15132787302635646979@ietfa.amsl.com> <50bdcf46-de26-66cd-415d-0c964fd38d57@gmail.com> <915CA4E0-D278-4BCA-B271-CC3BA8177CB8@employees.org> <864efe39-9759-d10b-1dce-27485ab743c1@gmail.com> <9873CDF0-8415-4B9E-8854-5D207BB2FF37@employees.org> <27a0b169b8774ada8558f1c1606ad8fe@XCH15-01-07.nw.nos.boeing.com> <6.2.5.6.2.20180623052647.0c968b90@elandnews.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] SAILing LAPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 18:27:15 -0000 I've a -bis version for RFC6177, which I drafted a couple of months ago, bu= t I need to coordinate with my co-author (one of the original RFC6177 autho= rs), hopefully during next week. I was trying, precisely to fix there all the related discussions on the /64= and the /48 boundaries ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Philip Homburg Fecha: s=C3=A1bado, 23 de junio de 2018, 19:46 Para: CC: S Moonesamy Asunto: Re: [v6ops] SAILing LAPs >There was a discussion about recommendations of the IETF about IPv6=20 >address assignments and it ended with a RFC 6177. I suggest reading= =20 >the summary of that discussion (in Section 5). =20 Unfortunately, RFC 6177 contains exactly the worrying arguements that should encourage drawing a line in the sand and keeping the 64 bit boundary. =20 The IETF had clear technical ideas why customers should get a /48. =20 It is possible that the IETF mis-understood operational concerns. Howev= er, RFC 6177 does not discuss clear operational problems with /48. Instead we get the following text: =20 "While the /48 recommendation does simplify address space management "for end sites, it has also been widely criticized as being wasteful. "For example, a large business (which may have thousands of employees) "would, by default, receive the same amount of address space as a home "user, who today typically has a single (or small number of) LAN and a "small number of devices (dozens or less). =20 It is clear that operators consider bits to precious without any operat= ional reason behind that. What are the benefits of providing customers with longer prefixes? We don't know. =20 So reality is that operators cannot know what a customer really needs. = They have some model of what a customer should need according to them, and t= he possibility to upsell. =20 So instead of having clear guide lines that customers need to get a /48= , we now have a discussion on subdividing /64s. =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Jun 24 19:23: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 196A9130E87; Sun, 24 Jun 2018 19:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bn7Ym0v46Ao; Sun, 24 Jun 2018 19:23:27 -0700 (PDT) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213F4124BE5; Sun, 24 Jun 2018 19:23:27 -0700 (PDT) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id F1C52E3597; Sun, 24 Jun 2018 22:23:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=JGy ML+4Ljc2nrJ5dBEA3ZAedLbQ=; b=GicBxzawZ9qqgZ9zPb93Sk2qmel1Z8TwGG4 4fMrgmhSTNo9F3n/Gd7zLNMY+h3YZZQLiuVydTIOanfP1d5Dqcf9C/dYdrzXOhI5 RpKvQ/4Guhkz2m5YQXelZ/272OuMOr17L7FiczVErmhY+Ba/whHmgNuJeV0STN6V RLroNTxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= uE9lfCHIrcUf40b8TEcDOMIrVXiDceky167ptpoTLDp3k6PBE2fFiJamSWiq3N5O HCDArTLWv5VPyD3VjwgwVDIAtGauAMUHU29juHlATjmSsPsFUMWg5rIrolBpEe2o vSxepcvCW/nf+h14EEza01ABoskCAGcXEqN9cZXd7e0= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id DE379E3596; Sun, 24 Jun 2018 22:23:25 -0400 (EDT) Received: from mail-oi0-f52.google.com (unknown [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 5A736E3593; Sun, 24 Jun 2018 22:23:25 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id b5-v6so1907031oiy.11; Sun, 24 Jun 2018 19:23:25 -0700 (PDT) X-Gm-Message-State: APt69E2wJAzjSIh0Oio2/uron/cq0rk5qlxrsk6wlxO7nfTqeAlnW6pr W3Y4ph9BEvoFEwCF/8q2T1ytEp5Bd4JHQvAg74Q= X-Google-Smtp-Source: ADUXVKKrHaDkkE9r0n13JpUlheUVNJ4BTUUAYAydYd3qnbnjz0V7lLwDxZwmm4cf04uQ0ZGSRQQv0cST/KZGFdYB3bo= X-Received: by 2002:aca:e4c8:: with SMTP id b191-v6mr5439239oih.106.1529893404781; Sun, 24 Jun 2018 19:23:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:7044:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 19:23:04 -0700 (PDT) From: "C. M. Heard" Date: Sun, 24 Jun 2018 19:23:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: JORDI PALET MARTINEZ Cc: 6man , v6ops Content-Type: multipart/alternative; boundary="000000000000efb4e2056f6e10a0" X-Pobox-Relay-ID: BD3A6996-781E-11E8-89B1-0DFB1A68708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [v6ops] SAILing LAPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 02:23:29 -0000 --000000000000efb4e2056f6e10a0 Content-Type: text/plain; charset="UTF-8" A 6177bis document is exactly the right place to reiterate this stuff. I look forward to seeing your draft. On Sat, 23 Jun 2018 20:27:02 +0200, JORDI PALET MARTINEZ wrote: > I've a -bis version for RFC6177, which I drafted a couple of months ago, > but I need to coordinate with my co-author (one of the original RFC6177 > authors), hopefully during next week. > > I was trying, precisely to fix there all the related discussions on the > /64 and the /48 boundaries ... > > Regards, > > Jordi > > --000000000000efb4e2056f6e10a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A 6177bis document is exactly the right place to reit= erate this stuff. I look forward to seeing your draft.=C2=A0
=
On Sat, 23 Jun 2018 20:27:02 +0200, JORDI PALET MARTINEZ=C2= =A0wrote:
I've a -bis version for RFC6177, w= hich I drafted a couple of months ago, but I need to coordinate with my co-= author (one of the original RFC6177 authors), hopefully during next week.= =C2=A0

I was trying, precisely to fix there all the related discussions on the /6= 4 and the /48 boundaries ...

Regards,

<= div class=3D"gmail_extra">Jordi

<= /div>
--000000000000efb4e2056f6e10a0-- From nobody Sun Jun 24 21:18: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 F24F61277CC for ; Sun, 24 Jun 2018 21:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IakJ0Y9v7H3n for ; Sun, 24 Jun 2018 21:17:59 -0700 (PDT) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::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 BA36012777C for ; Sun, 24 Jun 2018 21:17:59 -0700 (PDT) Received: by mail-ot0-x244.google.com with SMTP id i17-v6so2721749otl.1 for ; Sun, 24 Jun 2018 21:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=TaHh9ojtchyFXUzNZwMjprU3IPM9dyYnfb8/NHRsy4g=; b=ve+SVvgopBVX+gLEzI/vkzap3vLltvrjJ5yxbbIJd+zzBVmtninjjk4lmBXekbmuhN RatYJ5arihDqABRF2hSfGx676y5FYPbu/Moy4v9vT1ksoRe0H0VbmrH5lfrGAyyi2L4/ GkGvQHevc72I6PQKUa0uPFUOeTWkELuBcBJ7z3/XOZadcowsc6ijTfkk0CVl0ZgBErSA 7y1rOWj+5AWVq45mEglC1QxuB0m3FdXoowauKhlBrDdG8JHWYprIZCImvHNPuok8MdFK qum86GBO5H7iHg7rNQS3khlSC0i/zDeAIi23kw0lEG/RBVJgfJ2u6C/G0eys0qBR01Mu ItnA== 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=TaHh9ojtchyFXUzNZwMjprU3IPM9dyYnfb8/NHRsy4g=; b=ZiwUxkvJ14Hx9cH1ctTwNVxWZbzObQQfjjUpIHS0AyVVAtbQdjdXsA9HWrR7sH9IE8 qu1wE2w8lphNIIMD7MSEA/a4NowIqGYsXubR0uKsHU6PSvWvFKvTDAh5UsfvdrD1BL1x 2Wk584uDqvQEIrrmVEKOexErfPZcXqS/TdekX1UzIgFfytvtOeSfp2VCXL4HhbMGNSBj +cdHfwYhqvJbRLjEtmU+MhwLR3sL1P6VZs2mZoXe3o7PXqwlvJmfBJYO1yxOfpLi7aUs 5vH8klTYVCcgmsG+JnrfxSlyWsZWfafGSosn/mc2jYbIT4t+ECnNOTcX67Qsmhsen2bS bAWw== X-Gm-Message-State: APt69E0w4z29LvoZKV0WCRXRy91v8ItRp6XBYtEC7/CEW4IQc/XS7zAG 5FYP6t+eotnXY19o2ceImS7Y0FoKlpjeSuYNK2tz69y8 X-Google-Smtp-Source: AAOMgpdPXmJi7PzxJUJwiWqqJbrCVvNP4SW8P69AVClriaEl0Iy3JlmvJeZqd+HqjYq7tIncYiiFesxs/v6nGX20s0U= X-Received: by 2002:a9d:4c7:: with SMTP id 65-v6mr3271765otm.144.1529900278796; Sun, 24 Jun 2018 21:17:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:51c4:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 21:17:58 -0700 (PDT) From: nalini elkins Date: Mon, 25 Jun 2018 09:47:58 +0530 Message-ID: To: v6ops list Content-Type: multipart/alternative; boundary="000000000000a8e72f056f6faa37" Archived-At: Subject: [v6ops] IPv6 and Enterprises X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 04:18:01 -0000 --000000000000a8e72f056f6faa37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, If any in v6ops are interested, we discuss topics with enterprises at our "New Technology Briefings" which have generally been co-located with IETF meetings. The next one will be in Montreal on Saturday, July 14th. I believe we could take about 5 or 6 people. Please respond to me unicast if you are interested. It would be a good opportunity to meet / talk with enterprises f2f. IPv6 implementation at "brick and mortar" enterprise networks has lagged that of other sectors. We will be discussing reasons to migrate. Our current lineup of speaker for IPv6 include:=E2=80=8B - Improved Response Time with IPv6: Lee Howard - SDWan and IPv6 : Friso Feenstra (RaboBank) - IPv6-Only Performance and Diagnostic Information: Mike Ackermann (Blue Cross Blue Shield of Michigan) - IPv6 Business at Scale: E. Marie Brierley (former project manager at Cisco) - Getting IPv6 from ARIN Is Easy: John Sweeting, Senior Director of Registration Services, American Registry for Internet Numbers (ARIN) We will also be discussing other topics: Routing & IPWave. Please contact me, if you are interested & I will give you the location / registration information. --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000a8e72f056f6faa37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,


If any in v6ops are int= erested, we discuss topics with enterprises at our "New Technology Bri= efings" which have generally been co-located with IETF meetings.=C2=A0= The next one will be in Montreal on Saturday, July 14th.=C2=A0 =C2=A0I believe we could = take about 5 or 6 people.=C2=A0 Please respond to me unicast if you are int= erested.=C2=A0 =C2=A0It would be a good opportunity to meet / talk with ent= erprises f2f.


IPv6 implementation= at "brick and mortar" enterprise networks has lagged that of oth= er sectors.=C2=A0 We will be discussing reasons to migrate.=C2=A0 Our curre= nt lineup of speaker for IPv6 include:=E2=80=8B

=C2=A0

  • Improved Response Time with IPv6:=C2=A0Lee Howard

  • SDWan and IPv6 :=C2=A0Friso Feenstra=C2=A0(RaboBank)

    • =

  • IPv6-Only Performance and Diagnostic Information= :=C2=A0Mike Ack= ermann=C2=A0(Blue Cross Blue Shield of Michigan)

  • IPv6 Business at Scale:=C2=A0E. Marie Brierley= =C2=A0(former project manager at Cisco)

  • Getting IPv6 from=C2=A0ARIN Is Easy:=C2=A0John Sweeting,=C2=A0Senior Director of Registra= tion Services,=C2=A0=C2=A0American Registry for Internet Numbers (ARIN)=C2= =A0


    • We will also be discussing other topi= cs: Routing & IPWave.

    Please contact me, if you are interested & I will give y= ou the location / registration information.

    --
    <= div dir=3D"ltr">
    Thank= s,
    Nalini Elkins
    President
    Enterprise D= ata Center Operators

    --000000000000a8e72f056f6faa37-- From nobody Mon Jun 25 00:40:21 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 A7908130EC0; Mon, 25 Jun 2018 00:40:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152991240953.6305.13394976711538807769@ietfa.amsl.com> Date: Mon, 25 Jun 2018 00:40:09 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 07:40:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-04.txt Pages : 21 Date : 2018-06-25 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 25 00:51: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 79FB81292F1 for ; Mon, 25 Jun 2018 00:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si3tK7Ig0Zqy for ; Mon, 25 Jun 2018 00:51:52 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263F3130934 for ; Mon, 25 Jun 2018 00:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529913109; x=1530517909; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=WVbw9vzO pfQG8/jcU3mrqgDALFFv0p4kBFDhk4iEcZI=; b=QifFNYve+ABunumL2BssyUsd JWEWzUhG1fM2UkwZJV2o+2b8aZcqtq+o+yVOkzLhF8rwKwFmJTev4sa3D+jjNKqT z50mQ2yAMMambePsaD138vM0JFmdyaPqAIRXwU3WRjfZU9hwmdCq/yQCNVjK2qol riG8nowNrxdn3ZE3M78= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 25 Jun 2018 09:51:49 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Jun 2018 09:51:48 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005796152.msg for ; Mon, 25 Jun 2018 09:51:48 +0200 X-MDRemoteIP: 2001:470:1f09:495:fc83:2cd1:2320:e9e2 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Mon, 25 Jun 2018 09:51:48 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=171465a3f9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Mon, 25 Jun 2018 09:51:48 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <73CDA76D-24CD-4F3E-8A33-D6674CF5C284@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt References: <152991240953.6305.13394976711538807769@ietfa.amsl.com> In-Reply-To: <152991240953.6305.13394976711538807769@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 07:51:56 -0000 Hi all, We have uploaded a new version of this draft. No major changes, just the text for the transition requirements (but not an= actual change from the previous version). https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: lunes, 25 de junio de 2018, 9:42 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-04.txt Pages : 21 Date : 2018-06-25 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-04 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -04 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Jun 25 10:27: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 40C7E130F1B for ; Mon, 25 Jun 2018 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYfUepwisUQq for ; Mon, 25 Jun 2018 10:27:03 -0700 (PDT) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE5E130F29 for ; Mon, 25 Jun 2018 10:27:03 -0700 (PDT) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 41Dx1d2PY8zyWb for ; Mon, 25 Jun 2018 19:27:01 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-type:content-type:content-language :accept-language:message-id:date:date:subject:subject:from:from :received:received:received:received; s=postout; t=1529947620; bh=jblNjP4wyVz6NlfheUznEPbnhQ7ED1CpHu0saj51yIc=; b=pmWuS0RfZtOT jtccrMkfHwWDf8KkSdTJSQbAH8ioZFFt/+tkeYO/rfPKef4nkw32na9sJY/Su3sd cNyPJpzoO8X9Ll03y/nRH0QsbhCzVRus4iAx9prrCpO3WJTHSnCNf79nJIY/RmN7 oSdGm099yGF39ltAvN6XpRAndzj+7iuGFYnlvvPNTDsnGedwgkzprStCJSjc7q9L 3X32Q9kKATmPzQ5Wxkxa9M3I8SnXaZgNaMlxOLlijKbnnxlaRlKiz2JrXKV/Q38R AGgXZd9lmKrWtTwwW37lWDBAuetOyVHFOdUywbczPxgXZj6M1sVDFZH9UuRMMKo/ x2FLqAY5gA== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id vGeRNZTsK3YF for ; Mon, 25 Jun 2018 19:27:00 +0200 (CEST) Received: from BADWLRZ-SWMBX02.ads.mwn.de (BADWLRZ-SWMBX02.ads.mwn.de [IPv6:2001:4ca0:0:108::158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX02", Issuer "BADWLRZ-SWMBX02" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 41Dx1c6C7rzyWF for ; Mon, 25 Jun 2018 19:27:00 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de (2001:4ca0:0:108::167) by BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 25 Jun 2018 19:26:57 +0200 Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014]) by BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014%13]) with mapi id 15.01.1466.008; Mon, 25 Jun 2018 19:26:57 +0200 From: "Bajpai, Vaibhav" To: "v6ops@ietf.org" Thread-Topic: on google v6 stats Thread-Index: AQHUDKm37GY5iEbz60ebTQUHzy6hLw== Date: Mon, 25 Jun 2018 17:26:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BADWLRZ-SWMBX11.ads.mwn.de X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [92.218.255.204] Content-Type: multipart/signed; boundary="Apple-Mail=_0723D51B-E237-44B1-872F-EA98F251CFB7"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [v6ops] on google v6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 17:27:17 -0000 --Apple-Mail=_0723D51B-E237-44B1-872F-EA98F251CFB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, re: https://www.google.com/intl/en/ipv6/statistics.html a] How does Google count 'users' on the Google v6 adoption page? What happens when a user has (multiple) v6 privacy addresses that change with time, does each privacy address count as a single user? b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017 with an exponential jump in Apr/2018, with a recent sudden drop back to zero. Does anybody have insights on what is causing this observation or is this a measurement error? https://goo.gl/CwnKSm Thanks! -- Vaibhav ------------------------------ Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Fellow Technische Universit=C3=A4t M=C3=BCnchen ------------------------------ --Apple-Mail=_0723D51B-E237-44B1-872F-EA98F251CFB7 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 iQEzBAEBCgAdFiEEfIEt1NR2K2XOrjxAdHdcrBNYo5kFAlsxJeAACgkQdHdcrBNY o5naeAf/erj1Ja6a0qSuem4RUhjMgwuU7STkG7LSqhCNyNSD6/TCyquseiYLNeqF iOLQBsI38Dqro1hRFnGDO5aOnDpJetWAy42FOpj8JkSudgicc3APaCUz5t/cYNpI s0FjgFw8Mf7j78ZtASdX/IGLF8+Mjcy9mDQuU/i6p6mKKEiFXEPH9fd39SZzsJdb +ihQUfEralNcim4kQbXJSMcyELE8JqCflSn+D2MFkleyenOsr+tcDV1TNCj8ewtf KbNCls3MDV0eE83DVFffH2LkDzjLHpzSEy5/ebF2lU74QiUmV6LJWMr4eq78pUYq gczFe5+ZCpRqw54nHJE4OQgGm8QXWQ== =l8yQ -----END PGP SIGNATURE----- --Apple-Mail=_0723D51B-E237-44B1-872F-EA98F251CFB7-- From nobody Mon Jun 25 13:24: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 5F85D130E40 for ; Mon, 25 Jun 2018 13:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl3E44SVu7VG for ; Mon, 25 Jun 2018 13:24:25 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E3B130E3F for ; Mon, 25 Jun 2018 13:24:25 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id n2-v6so3126596pgq.6 for ; Mon, 25 Jun 2018 13:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kP/EGR9XMH1/0w3y5n7aTs+U1taj5pYIZ/wk6H/LZYE=; b=Jft3drNEZNmt7dN2gR4ED+FGYjq7WjRKEamvzDcb/KXTV1CY4ALh+FSpB0bSw2P73b U5e2kpgi8bvVyLmzHq8eWjjcoomOqz829VNyFfRVLEc7b6B5NjoFOMyCAytAru3AhU2n KTWGUIGgJmVPINGggSJce3vXq4+HVcuWzJDoWXGhB+Nio43qGMmr9BlevzG65udvOxRO P1j33LSbHDF4rW9aycCLS04s2i4SxH9AXq+yGB68GUkKh1RgbBrjkA77r0KEjmXj0sqz NXYi4P+ktN2+0xGEDa+Z/wQNLEpeJdQJKFtX9dO61ZxtfXAFzfEQ5fcwzoAcE3Sxy4zQ 0GuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kP/EGR9XMH1/0w3y5n7aTs+U1taj5pYIZ/wk6H/LZYE=; b=DBk2o4OeyKaxm+yYu9l+eOSgkUUB0+WgfCLy/KKQeTGSKmni4k7m6Wtj37knhL3LWG UJuqf7AH5PivTqeOPmAudqBXoUcgo3mlQ6WGOG6moT7qogJ+rZBOLAZHeHZwwdvG8gR3 IadgtZiQNh3PpGjHVbpQA0TjjDAqbUHNvjnccUX2+0bAJ4UT1DV9gPZuSbBsVAWwIo85 STvzeyPJmwtLUBVdxGPZ3MVJVn0AyfwqQ43YV0vQjmOUldEmIwvOMpmzqYlvQLn+KaTt dFeabIFVrUKqdqXe5hE3FvqO3U7O+iL2R/1JP8mNgM2xxVu7tR+7kg6VvXVTpkj6srnV kGgQ== X-Gm-Message-State: APt69E0BknJq5gS4OJcBFHpJz4PmRW0MeeqGQk9MvFiOsgA9aoo71IGB +PQ+ltaC3ezl1jjT3FSKuwb0Vg== X-Google-Smtp-Source: ADUXVKIG3BhpbIR29kq8uQ9F+yKaJG8kQWS1ymddjSES/eNt8YrT+5jckaP3YsDlDHIgAincxwvz0w== X-Received: by 2002:a65:611a:: with SMTP id z26-v6mr11838540pgu.61.1529958264489; Mon, 25 Jun 2018 13:24:24 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id l1-v6sm12065953pgn.55.2018.06.25.13.24.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 13:24:23 -0700 (PDT) To: v6ops@ietf.org References: <152991240953.6305.13394976711538807769@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <79ebe7c0-83f1-42dd-1415-5359cedad972@gmail.com> Date: Tue, 26 Jun 2018 08:24:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152991240953.6305.13394976711538807769@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 20:24:28 -0000 Hi, > TRANS-2: The IPv6 Transition CE Router MUST have a GUI and/or CLI > option to manually enable/disable each of the supported > transition mechanisms. I think this should be slightly extended to say "GUI, CLI and/or API option". In fact an API seems like the fundamental requirement, so that any kind of management mechanism could be applied. Regards Brian Carpenter On 25/06/2018 19:40, internet-drafts@ietf.org 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 Customer Edge Routers to Support IPv4 Connectivity as-a-Service > Authors : Jordi Palet Martinez > Hans M.-H. Liu > Masanobu Kawashima > Filename : draft-ietf-v6ops-transition-ipv4aas-04.txt > Pages : 21 > Date : 2018-06-25 > > Abstract: > This document specifies the IPv4 service continuity requirements for > an IPv6 Customer Edge (CE) router, either provided by the service > provider or thru the retail market. > > Specifically, this document extends the "Basic Requirements for IPv6 > Customer Edge Routers" in order to allow the provisioning of IPv6 > transition services for the support of "IPv4 as-a-Service" (IPv4aaS) > by means of new transition mechanisms. The document only covers > transition technologies for delivering IPv4 in IPv6-only access > networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required > in a world where IPv4 addresses are no longer available, so hosts in > the customer LANs with IPv4-only or IPv6-only applications or > devices, requiring to communicate with IPv4-only services at the > Internet, are still able to do so. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-04 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . > From nobody Mon Jun 25 14:24: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 A80AF130DF1 for ; Mon, 25 Jun 2018 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94DrfSQzHBNn for ; Mon, 25 Jun 2018 14:24:21 -0700 (PDT) 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 939F8130E58 for ; Mon, 25 Jun 2018 14:24:21 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob20.registeredsite.com (8.14.4/8.14.4) with ESMTP id w5PLOIFF005614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 25 Jun 2018 17:24:19 -0400 Received: (qmail 4985 invoked by uid 0); 25 Jun 2018 21:24:18 -0000 X-TCPREMOTEIP: 199.187.222.168 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?199.187.222.168?) (lee@asgard.org@199.187.222.168) by 0 with ESMTPA; 25 Jun 2018 21:24:18 -0000 To: v6ops@ietf.org References: From: Lee Howard Message-ID: Date: Mon, 25 Jun 2018 15:24:16 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8AF11C9A03BE2FBA45343137" Content-Language: en-US Archived-At: Subject: Re: [v6ops] on google v6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 21:24:24 -0000 This is a multi-part message in MIME format. --------------8AF11C9A03BE2FBA45343137 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 06/25/2018 11:26 AM, Bajpai, Vaibhav wrote: > Hello, > > re: https://www.google.com/intl/en/ipv6/statistics.html > > a] How does Google count 'users' on the Google v6 adoption page? What > happens when a user has (multiple) v6 privacy addresses that change > with time, does each privacy address count as a single user? I am not authoritative, but here's what they say: *Google*: We measure IPv6 adoption among Google users by adding measurement JavaScript to a random sample of visits to various Google properties. The methodology is similar to that described in our paper,Evaluating IPv6 adoption in the Internet . The JavaScript uses HTTP to fetch a URL from an IPv4-only hostname and a URL from a dual-stack hostname, in random order, and then reports the results. The measurement is attributed to the ASN that originates the user's IPv4 address. Measurement endpoints use the same infrastructure that serve regular Google traffic. http://www.worldipv6launch.org/measurements/ > > b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017 > with an exponential jump in Apr/2018, with a recent sudden drop back > to zero. Does anybody have insights on what is causing this observation > or is this a measurement error? > > https://goo.gl/CwnKSm Google shows .03% in April 2017, a brief spike in May 2018 to .011%%, and now down to 0.00%. https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption&tab=ipv6-adoption Facebook looks similar, except for that one spike. I would treat that as an anomaly, the kind of noise one expects to see in live data. And I'd say 0.00% is pretty good. Lee > > Thanks! > > -- Vaibhav > > ------------------------------ > Vaibhav Bajpai > www.vaibhavbajpai.com > > Postdoctoral Fellow > Technische Universität München > ------------------------------ > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------8AF11C9A03BE2FBA45343137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 06/25/2018 11:26 AM, Bajpai, Vaibhav wrote:
    Hello,

re: https://www.google.com/intl/en/ipv6/statistics.html

a] How does Google count 'users' on the Google v6 adoption page? What
happens when a user has (multiple) v6 privacy addresses that change
with time, does each privacy address count as a single user?

    I am not authoritative, but here's what they say:
    Google: We measure IPv6 adoption among Google users by adding measurement JavaScript to a random sample of visits to various Google properties. The methodology is similar to that described in our paper, Evaluating IPv6 adoption in the Internet. The JavaScript uses HTTP to fetch a URL from an IPv4-only hostname and a URL from a dual-stack hostname, in random order, and then reports the results. The measurement is attributed to the ASN that originates the user's IPv4 address. Measurement endpoints use the same infrastructure that serve regular Google traffic.
    http://www.worldipv6launch.org/measurements/




     
    
b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017
with an exponential jump in Apr/2018, with a recent sudden drop back
to zero. Does anybody have insights on what is causing this observation
or is this a measurement error?

https://goo.gl/CwnKSm


    Google shows .03% in April 2017, a brief spike in May 2018 to .011%%, and now down to 0.00%.
    https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption&tab=ipv6-adoption

    Facebook looks similar, except for that one spike. I would treat that as an anomaly, the kind of noise one expects to see in live data. And I'd say 0.00% is pretty good.

    Lee

    
Thanks!

-- Vaibhav

------------------------------
Vaibhav Bajpai
www.vaibhavbajpai.com

Postdoctoral Fellow
Technische Universität München
------------------------------




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

    --------------8AF11C9A03BE2FBA45343137-- From nobody Mon Jun 25 15:21: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 1BB27130E4C for ; Mon, 25 Jun 2018 15:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew8WPhtoDOAz for ; Mon, 25 Jun 2018 15:21:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4A5130E17 for ; Mon, 25 Jun 2018 15:21:31 -0700 (PDT) Received: from static-219-180.meetings.nanog.org ([IPv6:2620:0:ce0:101:ecc3:191e:c836:49f1]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w5PMLRES008134 for ; Mon, 25 Jun 2018 22:21:30 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:0:ce0:101:ecc3:191e:c836:49f1] claimed to be static-219-180.meetings.nanog.org To: V6 Ops List From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: Date: Mon, 25 Jun 2018 16:21:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [v6ops] https://datatracker.ietf.org/doc/draft-jaeggli-v6ops-indefensible-nd/ - explination X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 22:21:33 -0000 Hi, I submitted this draft as a talking point to the discussion in 6man related to IID prefix length.=C2=A0 =C2=A0SAILing LAPs - currently at 72 messages and counting The draft is specifically related to work previously done in v6ops (rfc 6583) rather than 6man and does not itself propose an protocol changes hence my inclusion of the v6ops label. I have not specific goals for advancement or adoption at this time apart from making a point about NDP mitigitations and in particular variable length subnet masks. Thanks joel From nobody Mon Jun 25 23:42: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 DDDA7130E67 for ; Mon, 25 Jun 2018 23:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUF-7bFOYyZP for ; Mon, 25 Jun 2018 23:42:26 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947B1130DE6 for ; Mon, 25 Jun 2018 23:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1529995342; x=1530600142; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=KRpeKSnI C3l4r5lvj6t9S16UWfZ7CNCufaJGGhvoT7Q=; b=rrcH5C5RpZaKRTS9n9GqGSgK Z9/zSMby72QMLv6ow0g76FVTT5v+n6I+aDMnP4pMI+di7V9Ty62wd85iCzPcCBjn 8EfQ5sxxiMZzFnBOXOhbbFofZbrRs5eiCdKd01zcN62zkt9cRh8/4I2hs1EaaVPA E3Xz3S8RKzzJ+rPXJMY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 26 Jun 2018 08:42:22 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 26 Jun 2018 08:42:22 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005797853.msg for ; Tue, 26 Jun 2018 08:42:21 +0200 X-MDRemoteIP: 2001:470:1f09:495:f1ab:45ed:3a80:3e06 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Tue, 26 Jun 2018 08:42:21 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1715748e29=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Tue, 26 Jun 2018 08:42:21 +0200 From: JORDI PALET MARTINEZ To: Brian E Carpenter , Message-ID: <7B3B5EC9-BEF2-4A38-A341-C312C97AFEF2@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt References: <152991240953.6305.13394976711538807769@ietfa.amsl.com> <79ebe7c0-83f1-42dd-1415-5359cedad972@gmail.com> In-Reply-To: <79ebe7c0-83f1-42dd-1415-5359cedad972@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 06:42:29 -0000 Thanks a lot Brian, Yes, makes a lot of sense! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Fecha: lunes, 25 de junio de 2018, 22:25 Para: Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-04.txt Hi, =20 > TRANS-2: The IPv6 Transition CE Router MUST have a GUI and/or CLI > option to manually enable/disable each of the supported > transition mechanisms. =20 I think this should be slightly extended to say "GUI, CLI and/or API op= tion". In fact an API seems like the fundamental requirement, so that any kind of management mechanism could be applied. =20 Regards Brian Carpenter =20 =20 =20 On 25/06/2018 19:40, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Requirements for IPv6 Customer Edge Routers= to Support IPv4 Connectivity as-a-Service > Authors : Jordi Palet Martinez > Hans M.-H. Liu > Masanobu Kawashima > Filename : draft-ietf-v6ops-transition-ipv4aas-04.txt > Pages : 21 > Date : 2018-06-25 >=20 > Abstract: > This document specifies the IPv4 service continuity requirements f= or > an IPv6 Customer Edge (CE) router, either provided by the service > provider or thru the retail market. >=20 > Specifically, this document extends the "Basic Requirements for IP= v6 > Customer Edge Routers" in order to allow the provisioning of IPv6 > transition services for the support of "IPv4 as-a-Service" (IPv4aa= S) > by means of new transition mechanisms. The document only covers > transition technologies for delivering IPv4 in IPv6-only access > networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as requir= ed > in a world where IPv4 addresses are no longer available, so hosts = in > the customer LANs with IPv4-only or IPv6-only applications or > devices, requiring to communicate with IPv4-only services at the > Internet, are still able to do so. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-04 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv= 4aas-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4a= as-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Jun 26 02:45: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 4D62B130EC0 for ; Tue, 26 Jun 2018 02:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=tum.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbO7C2c_HLmt for ; Tue, 26 Jun 2018 02:45:29 -0700 (PDT) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2074D130F91 for ; Tue, 26 Jun 2018 02:45:28 -0700 (PDT) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 41FLkb2vyzzyWh; Tue, 26 Jun 2018 11:45:27 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-type:content-type:content-language :accept-language:in-reply-to:references:message-id:date:date :subject:subject:from:from:received:received:received:received; s=postout; t=1530006326; bh=1yZ9D1h9ERE3TEssAJuomci1vKdPd7Kdxns h/ugXa0M=; b=kiCZMThi9Z+sxt2JFBfXFcrBh8BE0butwftqaIf5OAacaYnc3yB AzKglqLop15VDQjw6Im3V2vtteFB3QWKg6vuZpCf78PzdPOeI1YHQki3vpPI/JMt ho5r95Wjg6dCS5O0GlvWGOZZCpBxef1ouZH+VHt3i2DAqDS+ZSsf9/BoLvuZx7nu lL1jrSp79SeId2rQlTgNNlVcVUYvd+UNamX+ftQAEwqmwAM3Ninau/nS5c6jTAx5 4ImCnSBTtf0N2vOYOuDbNf+Utffd8yBskGtCU+3LB7bqRGtY+9vnm9qJW8wr6bre b3Ye/ZW73KBjLqZ4YmVUIBqKpD9w+i3vJfA== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 2Cs9xTrtzIsN; Tue, 26 Jun 2018 11:45:26 +0200 (CEST) Received: from BADWLRZ-SWMBX07.ads.mwn.de (BADWLRZ-SWMBX07.ads.mwn.de [IPv6:2001:4ca0:0:108::163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX07", Issuer "BADWLRZ-SWMBX07" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 41FLkZ2xgxzyW9; Tue, 26 Jun 2018 11:45:26 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de (2001:4ca0:0:108::167) by BADWLRZ-SWMBX07.ads.mwn.de (2001:4ca0:0:108::163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 26 Jun 2018 11:45:24 +0200 Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014]) by BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014%13]) with mapi id 15.01.1466.008; Tue, 26 Jun 2018 11:45:23 +0200 From: "Bajpai, Vaibhav" To: Lee Howard CC: "Bajpai, Vaibhav" , "v6ops@ietf.org" Thread-Topic: [v6ops] on google v6 stats Thread-Index: AQHUDMsBgUIMAdBnYUycQD5XJcOA8aRyKbIA Date: Tue, 26 Jun 2018 09:45:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BADWLRZ-SWMBX11.ads.mwn.de X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.159.24.54] Content-Type: multipart/signed; boundary="Apple-Mail=_F3E4A60C-EEA9-454E-9BB9-D0D9EF829ACB"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] on google v6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 09:45:33 -0000 --Apple-Mail=_F3E4A60C-EEA9-454E-9BB9-D0D9EF829ACB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, >> re: >> https://www.google.com/intl/en/ipv6/statistics.html >>=20 >>=20 >> a] How does Google count 'users' on the Google v6 adoption page? What >> happens when a user has (multiple) v6 privacy addresses that change >> with time, does each privacy address count as a single user? >>=20 >=20 > I am not authoritative, but here's what they say: > Google: We measure IPv6 adoption among Google users by adding = measurement JavaScript to a random sample of visits to various Google = properties. The methodology is similar to that described in our paper, = Evaluating IPv6 adoption in the Internet. The JavaScript uses HTTP to = fetch a URL from an IPv4-only hostname and a URL from a dual-stack = hostname, in random order, and then reports the results. The measurement = is attributed to the ASN that originates the user's IPv4 address. = Measurement endpoints use the same infrastructure that serve regular = Google traffic. > http://www.worldipv6launch.org/measurements I am not sure if the methodology used in the 2010 paper is still valid. For one, both hostnames do not have either A or AAAA records anymore (dualstack.ipv6-exp.l.google.com, ipv4.ipv6-exp.l.google.com). >> b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017 >> with an exponential jump in Apr/2018, with a recent sudden drop back >> to zero. Does anybody have insights on what is causing this = observation >> or is this a measurement error? >>=20 >> https://goo.gl/CwnKSm >=20 >=20 > Google shows .03% in April 2017, a brief spike in May 2018 to .011%%, = and now down to 0.00%. > = https://www.google.com/intl/en/ipv6/statistics.html#tab=3Dipv6-adoption&ta= b=3Dipv6-adoption >=20 > Facebook looks similar, except for that one spike. I would treat that = as > an anomaly, the kind of noise one expects to see in live data. And I'd = say 0.00% is pretty good. Oh, how do I see the facebook teredo/6to4 plot? This [a] seems to show overall v6 adoption. a] https://www.facebook.com/ipv6 > Lee -- Vaibhav ------------------------------ Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Fellow Technische Universit=C3=A4t M=C3=BCnchen ------------------------------ --Apple-Mail=_F3E4A60C-EEA9-454E-9BB9-D0D9EF829ACB 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 iQEzBAEBCgAdFiEEfIEt1NR2K2XOrjxAdHdcrBNYo5kFAlsyCzQACgkQdHdcrBNY o5nHQQf+I00+qnV1ACoN36kP1LM17zSdBPTgUkU2V2q84GYlCkxIDdb5h9S0pSgZ 0/kKWF4/gMzntmk8UbyHNP3zx2iqBP7U7NRCI32e7pRxovpECV2/zUZue6YWGx1c pbrqvMeYHlILpjXSh0qolxZsk5fRDHVlkTbTSgufBYphLgP1EH0ij4u9sLACiy2U GgIitJCa2w11cMMUqkNloYeePTQ2yTs9r2Iz7uJq2B6lPL/HsKUqCcMxCYRrWusl WmV6Eh//S1w9r0wllNLwPw5yZcVKN9E03jKVK/sToRN1WY0U+IuZWelu1lDylovX Ybk+xJXLA9ufk5oBxOOQyQWBnr+D7g== =8/Re -----END PGP SIGNATURE----- --Apple-Mail=_F3E4A60C-EEA9-454E-9BB9-D0D9EF829ACB-- From nobody Tue Jun 26 04:15: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 67F5712E039 for ; Tue, 26 Jun 2018 04:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 6d6rYGfif6Uh for ; Tue, 26 Jun 2018 04:15:14 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6119127598 for ; Tue, 26 Jun 2018 04:15:13 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id g18-v6so16822938wro.7 for ; Tue, 26 Jun 2018 04:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bLHSK5DleUX2P1PVYx0cpMfgMcTtO4FLae9vAc5p31c=; b=a3nXotlf/ZXBjJ3s3LocdcNuwc84Uh4W9MKgqnV4tZtuZTKMKaJkWYuJkW2muvxJWW dKheKFRAWxF1st/L7BzPUp+g16D4dM2MLJNcwEtP7wAa7Pj1Drbl9shTCwuq9Jy+6qEj 1R823vhCrkbHnLRJERsZyqNJeT8EzqknsrXXBqRvwbaRJf0yDwBkzMDFQw0sfMhsTfM2 zQvM9HOqzuVdnCQ1g2G0RlUSZC6nezADxJ66T1Cd0w0trphX9PhOSsvgvgIRRQOESyRw VRXQ0keOlrRN3hlImS02QQwNJjkPIMUbeupsiJXg7v/5mMJWSW/JHl9gYJq38xoeOl5u PS+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=bLHSK5DleUX2P1PVYx0cpMfgMcTtO4FLae9vAc5p31c=; b=XxBAH3tLdFLrZxBxXkLonFZyCWNtcYOFDYJEqET/GvDqNiauCM+Go6y4rfegyy7UA4 /TjrwkTnm65162NYQI/nm62a0MvzYHicPNQ8uKryutXVgzOAxlUJFe6KnwrxR6KHKfEY DINiWyiL7tCP8ifr0oeYHvvvC8si5gTd/zoS/AYmLH/In2dce35d+x5mC0dtOg6VOjmU eCC6/a5+35phBXkCd5OgyHXzhdlhIQqO+ZOjBVV+M01z9PDI0NFBJfWxOXS2/eFwMo99 5V+wtqq2ZXpeypAkmv1LEVtcj8UjsoIx7f+qzXERTR3W/CsAPUDfEPoNdhUGVmGKfubg Zv6g== X-Gm-Message-State: APt69E3vpj/NiAwVQbKHGEjGoprcdSv6PhOEELAItq0YAuw/sviJoOmf 96D2+9Ede/kLlNHgJBr3B2ek9uz4DdI0WLxkc/EswQ== X-Google-Smtp-Source: AAOMgpeBrfedNO1etEY1P5PHH00AbfyTLnhU3dnS0ubFn7VUza4OMGUA7sRgSa4du/dLtlbzL9cOyaiCXCQeKuaK22A= X-Received: by 2002:adf:fac6:: with SMTP id a6-v6mr1078358wrs.74.1530011711385; Tue, 26 Jun 2018 04:15:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Tue, 26 Jun 2018 20:14:57 +0900 Message-ID: To: vaibhav.bajpai@tum.de Cc: "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000996cd7056f899cdc" Archived-At: Subject: Re: [v6ops] on google v6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 11:15:16 -0000 --000000000000996cd7056f899cdc Content-Type: text/plain; charset="UTF-8" > b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017 > with an exponential jump in Apr/2018, with a recent sudden drop back > to zero. Does anybody have insights on what is causing this observation > or is this a measurement error? yeah, basically measurement error --000000000000996cd7056f899cdc 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8 LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2 9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgo3akZ7PydxFi9pGhXpg/D310gbABBTEx mg2YuEQG2kcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNjI2 MTExNTEyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJ+WLJI7/DurRC11NHlnLYVcd8l7iwOC/mfQy8PPEA6AoQqkb7h2 3VXRxlWsozexoBSJcuiF1ZN8C9y0oWPLKil7mHfur+xdDrCJ+SSndZ5Ldo6GKZZUeWIoYsW5nIQB hqhJYEnVSx/c2/fifNFTUtXYhCK9uY+YzAiuHou3hAD7AidULniurdkD86ZIcqIVnfx98A0QmuEh XO+NKpuq48oxBlZ6q9YA5Ij1bU2bGvQm0iacd0pZuP9cEgo9VTasksORufoK8SMmogsDBxc092ez 0RUPFlwTdHL4+mLfepKkYAQCRCIQkrvvWE+QeMhdd5sl9ga+cchHe4tCK6kbtp8= --000000000000996cd7056f899cdc-- From nobody Tue Jun 26 04:19: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 BAC19130E00 for ; Tue, 26 Jun 2018 04:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=tum.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m8cLzzDwG9z for ; Tue, 26 Jun 2018 04:19:31 -0700 (PDT) Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9462B12F1AB for ; Tue, 26 Jun 2018 04:19:31 -0700 (PDT) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 41FNq42zNpzyVd; Tue, 26 Jun 2018 13:19:28 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-type:content-type:content-language :accept-language:in-reply-to:references:message-id:date:date :subject:subject:from:from:received:received:received:received; s=postout; t=1530011968; bh=PTS4Oy7LaB7/lRGaIHYUEBEcBZhbLUVdVB+ LeapsUpU=; b=MgIrPiIa6kV86nxKOKNhD75w7u4CA9S0UgqkpcFOuwv3Fwu6hlN lyDMUkKxBjbB+/2IV1gq+r5MIbLuZRqoFx8gDsgfEGfs81YrQ4+jgkLfLDu+0QRB HhxgrhvQHNzjfQg3K2vJj24W09Xd9nOq26DnE/sK0LNxWW3fQhbMhMKph+RysbiE Dg642Cue/1Z4QeetnS7CNeaFC93mds5dSrCDtEE30ePWvr6Uxd2M4f771nkfmb4h PVOiH0JXzCISO0U7W21MUaYBQ1IwDALqHFbZNUwCN/8CG1LRVUF+FkVwa9dvZYpb xVBTKyX7VmhsaGl5uyHXcBUaIQOHAkbPBiw== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id EiuVunf7Mm26; Tue, 26 Jun 2018 13:19:28 +0200 (CEST) Received: from BADWLRZ-SWMBX10.ads.mwn.de (BADWLRZ-SWMBX10.ads.mwn.de [IPv6:2001:4ca0:0:108::166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX10", Issuer "BADWLRZ-SWMBX10" (not verified)) by postout2.mail.lrz.de (Postfix) with ESMTPS id 41FNq33n3tzyW3; Tue, 26 Jun 2018 13:19:27 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de (2001:4ca0:0:108::167) by BADWLRZ-SWMBX10.ads.mwn.de (2001:4ca0:0:108::166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 26 Jun 2018 13:19:21 +0200 Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014]) by BADWLRZ-SWMBX11.ads.mwn.de ([fe80::f0dd:745f:a1b4:5014%13]) with mapi id 15.01.1466.008; Tue, 26 Jun 2018 13:19:21 +0200 From: "Bajpai, Vaibhav" To: Erik Kline CC: "Bajpai, Vaibhav" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] on google v6 stats Thread-Index: AQHUDT7qgUIMAdBnYUycQD5XJcOA8aRyQwsA Date: Tue, 26 Jun 2018 11:19:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BADWLRZ-SWMBX11.ads.mwn.de X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.159.24.54] Content-Type: multipart/signed; boundary="Apple-Mail=_A786B8B4-9E36-46C2-B9AD-323A6FCBE30A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] on google v6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 11:19:34 -0000 --Apple-Mail=_A786B8B4-9E36-46C2-B9AD-323A6FCBE30A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, > On 26. Jun 2018, at 13:14, Erik Kline wrote: >=20 >> b] The rate of adoption of Teredo/6to4 started increasing in Apr/2017 >> with an exponential jump in Apr/2018, with a recent sudden drop back >> to zero. Does anybody have insights on what is causing this = observation >> or is this a measurement error? >=20 > yeah, basically measurement error Thank you. -- Vaibhav ------------------------------ Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Fellow Technische Universit=C3=A4t M=C3=BCnchen ------------------------------ --Apple-Mail=_A786B8B4-9E36-46C2-B9AD-323A6FCBE30A 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 iQEzBAEBCgAdFiEEfIEt1NR2K2XOrjxAdHdcrBNYo5kFAlsyIToACgkQdHdcrBNY o5l9Igf9Ean2Hz7GcSARuYxtb1ykXidsPFNswbd4SKG0TgGa3tmg1woYop2zw3xw mQAJb0ym3S5mt86jCEXC/Msx7noMy/c+vl20meVQuRAnapKZUCEn2gwklqfvTk3B mmWD0A0V9MQM4yt+fmpIU1lD9aaZ0ZM7nFRqiZZ9WXJnqDa1b9Bk5/GRnHHNh52Z Ipvx/toYdBqxR+Zv2yOf7D39Gl//zA98ceWBsS1Lq93D0dRwXBhmaaIl+Ot4boXd ok4049vRDpsSYXryVbmmQP2vM7d7ZJd69N3RivvRGNYeReZmYqtWgHaye8RAV3W6 EMlW5kwpQaHyr1WNzBhCT3KgaKvR7Q== =HYl0 -----END PGP SIGNATURE----- --Apple-Mail=_A786B8B4-9E36-46C2-B9AD-323A6FCBE30A-- From nobody Tue Jun 26 11:46: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 80E031310FE for ; Tue, 26 Jun 2018 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OaWV4woJrsB for ; Tue, 26 Jun 2018 11:46:45 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4680C1310F8 for ; Tue, 26 Jun 2018 11:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530038803; x=1530643603; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Hi668ecr uBFd8jpDsBBXDD1UtIqbxtcTjD6lcagUdrM=; b=RWw2kFjAlCIe9zikxYy3VDfG 2EQaIOiH0bZDRePCbYS/mhgh+wmlDQap3dDciNIKFRBvG/PwUlFMxPjJBSY1YMsW Ojy3ilSXY9vlrgplJRT6gvSl7mSvHJDSs0lI0YRmJ4xIxuJiBGB5ui3k/FQGHb/C Gt1zNbPhchmvR2iVRPk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 26 Jun 2018 20:46:43 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 26 Jun 2018 20:46:42 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005798382.msg for ; Tue, 26 Jun 2018 20:46:41 +0200 X-MDRemoteIP: 2001:470:1f09:495:9ab:5b38:10ba:8337 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Tue, 26 Jun 2018 20:46:41 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1715748e29=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Tue, 26 Jun 2018 20:46:40 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-palet-v6ops-nat64-deployment-02.txt References: <153003837565.18877.17637202111806852862.idtracker@ietfa.amsl.com> In-Reply-To: <153003837565.18877.17637202111806852862.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-nat64-deployment-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:46:49 -0000 Hi all, I just published a new version of this document: https://datatracker.ietf.org/doc/draft-palet-v6ops-nat64-deployment/?includ= e_text=3D1 I've tried to follow all the discussions bits that we had in the list, spec= ially the very detailed input from Andrew (thanks again for that). Hopefull= y I didn't forgot anything. Tried to make sure that the document clearly says that some of the scenario= s are "special cases", and that using or not DNS64 is an option, even if it= means breaking DNSSEC (in case there is host validation), which may be ass= umable in some scenarios. I've added a comparison among all the scenarios (and sub-scenarios, in tota= l 12), revised all the text, rearranged the sections, etc. I think now the document is easier to read/follow and more useful for provi= ders (and enterprises) that can use the document for taking decisions on do= ing one scenario or another one, being cautious about every possible issue. I've added some other sections (a couple of annexes) that have been suggest= ed in private, as needed by ISPs willing to deploy it. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: martes, 26 de junio de 2018, 20:39 Para: Jordi Palet , Jordi Palet Martinez Asunto: New Version Notification for draft-palet-v6ops-nat64-deployment-02.= txt =20 A new version of I-D, draft-palet-v6ops-nat64-deployment-02.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-nat64-deployment Revision: 02 Title: NAT64/464XLAT Deployment Guidelines in Operator and Enterprise = Networks Document date: 2018-06-26 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= nat64-deployment-02.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-nat6= 4-deployment/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-nat64-dep= loyment-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -nat64-deployment Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-n= at64-deployment-02 =20 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 operator (cellular and broadband) or enterprise network and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv= 4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 27 10:04:47 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 E6D95130DD9 for ; Wed, 27 Jun 2018 10:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEBwd7jAAgFu for ; Wed, 27 Jun 2018 10:04:39 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 06ADE124D68 for ; Wed, 27 Jun 2018 10:04:39 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id c41-v6so1331517plj.10 for ; Wed, 27 Jun 2018 10:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=wRxdcJnCkRNWneT+VJblYiN//5a/LV3WuhfFDWM7XIk=; b=J6qODb4O5MGHNiDkzzTo7PZeEOBb8Cor/2H23DgU5QqY0JxWpM2CCxlYC8qGwcsx6c h2/yvMYSHS/pCFSKqUupiHhmnvOfsK/Fa8MFzgmweqM3SjIfL8QfhEHhV/82XPqpEr3Y QRvIZrc0dngYc1wimv2iBdz13Nvcdwo6nDqAk+OcYatvXmWzLU1gSy+V/daZc6Tv6DpV qaC6EpLR+vx233uil37kH6FCsYWWKRw0nb+obf6vKU7+coodNYzxA69Yy31ksRG4EBJJ 0zLYhURQCvTCPolfsnGCkG5Mi0ZSAP1cGnk/EfP0HWZTlYvvLkr01XiaMaipbRmaZHTm PenQ== 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:message-id:to; bh=wRxdcJnCkRNWneT+VJblYiN//5a/LV3WuhfFDWM7XIk=; b=Ja3XLB5GbjfbuG08tDiCNKFOVp3r7pE6MCMpAt37XztCwahnzOwQGY6R6zGhfXnCIe Vqfd5IDvFLS/7v4dLStvR3p263DZA80swrLeGwplRif+DlN9pO5kw7Hk+akRS2fSUF85 cIH0Q8lg4lqoQL9qVj/rbkU49J8Kw4qCHlXPEfPNzA0yAfUyuX4ZRYUTxnAeKVp4vZqP fEERrm2tWUXHmn7YHAI7+e/Qer6A2/T5uQzy4DWOdAj0haQNb2B2npjZsPOc78gDURX6 NnOHIz3xzpUy3uS6xBFjDwE1fgAr2p4c8b5r/OHnnUR3GFvabCdHUylrgAjuCapRzgTv PDcg== X-Gm-Message-State: APt69E1wSwshXglsrgAVkA9batvuEr90Xy3DJdmKOoqonr30pk8+YN7d aVchha76bXv9FtAtq+mmDgrl9hD2 X-Google-Smtp-Source: ADUXVKLAE4R3b+RMDTfirf/ho6Qi/8e/DZTnvC33IqhJpwNV92vp5anmI0+ja+yo/vSPxKShzFCaag== X-Received: by 2002:a17:902:1e4:: with SMTP id b91-v6mr6994380plb.155.1530119078550; Wed, 27 Jun 2018 10:04:38 -0700 (PDT) Received: from [10.196.220.133] (41-197.icannmeeting.org. [199.91.197.41]) by smtp.gmail.com with ESMTPSA id 127-v6sm3228304pfe.0.2018.06.27.10.04.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 10:04:37 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_EE7756E6-37FB-47C1-9FCB-DE1D4614D84E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 27 Jun 2018 12:04:34 -0500 Message-Id: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> To: =?utf-8?Q?Jordi_Palet_Mart=C3=ADnez?= , "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 17:04:46 -0000 --Apple-Mail=_EE7756E6-37FB-47C1-9FCB-DE1D4614D84E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chair comment: I am interested in making this draft a working group = draft. I think there is merit in it to do so. However, following our = usual process, I need agreement from the working group. Consider this a = solicitation for that. To do so, I'm looking for comments, supportive or = otherwise, especially from operators. To respond to Barbara's question = that she raised with ipv4aas, making it a working group document doesn't = mean it's done, it means it's a work item as opposed to a suggestion to = the working group. The rest of this is sans hats. Thanks for your new draft. Let me say that I am increasingly hearing = about ISPs (cellular and broadband) that, in the words of one, "just = don't want to allocate IPv4 addresses anymore", and are taking important = steps toward turning IPv4 off within their networks in favor of IPv4 as = a service. As you know, this falls into a couple of categories - those = that are willing to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 = service, and those that need to be able to somehow still put an IPv4 = address into an A record (such as a company like Lumix that uses Dynamic = DNS Update and firewall hole-punching to allow a residential user to = access their surveillance system from an Android/iPhone app) and use it = to send a message to the IPv4 server. So IMHO, this is an important = draft, and it would be useful to get operator comment on it. I'm reviewing the draft. I'll bring up nits inline, and I may have some = other thoughts as well. > Abstract >=20 > This document describes how NAT64 and 464XLAT can be deployed in an > IPv6 operator (cellular and broadband) or enterprise network and = the I suspect that this would read better as "IPv6 network, whether cellular = ISP, broadband ISP, or enterprise". > 1. Introduction > To avoid changes in both, the IPv6-only hosts and the IPv4-only > server, NAT64 requires also the use of a DNS64 ([RFC6147]), in = charge > for the synthesis of AAAA records from the A records. I would disagree that NAT64 "requires" DNS64. NAT64 requires that the = destination IPv6 address contain an embedded IPv4 address. The source of = that IPv4-embedded IPv6 address is up to the system that sent the = packet. A CLAT (stateless translation as in RFC 7915) uses address = synthesis with a PLAT translation prefix. MAP-T adds NAPT44 = functionality to that with respect to the outbound IPv4 source address. = A random IPv6 host accessing an IPv4-only peer might use DNS64, and the = AAAA records might simply exist in DNS containing an IPv4-embedded IPv6 = address. But the NAT64 function doesn't use, nor does it require, DNS64. BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session = (effectively NAPT) translator, and provides translation strictly at the = IP layer. I suspect that is also a valid configuration, one that needs = to be supported. In the 464XLAT case, I think it falls out, but I'll = have to think about MAP-T. > 3. NAT64 Deployment Scenarios > Consequently, the perspective in this document is to broader those "broaden" > 3.1.2. Service Provider offering 464XLAT, with DNS64 Pictorial image of what I'm picturing: +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +--+--+ +--+-+ +------+ v6 +------+ | | | | +----+ | ,--+--. | ,--+--. |Dual | | IPv6 | / \ ,-+-. / \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ The dual stack device obviously has an IPv4 and an IPv6 address, and the = IPv4 side of it speaks through the CLAT. The IPv6 device has no IPv4 = address. The peer device is the thing the "dual stack" device connects = to, and might itself be dual stack or IPv4-only. In both cases, however, = IPv4 access to the peer device will go through the PLAT. When the IPv6 device wants to talk with the peer device, it will need a = AAAA record. In the dual stack case, that will contain a "usual" IPv6 = address, and connectivity will be IPv6 end to end; in the IPv4-only = case, it will need its IPv4 address embedded into the PLAT's translation = prefix, which is or is functionally equivalent to DNS64. When the dual stack device wants to talk with the Peer Device, its IPv4 = side will need an A record and the CLAT will do the address synthesis. = Hence, no need for DNS64, and no requirement for it if it exists. The = IPv6 side will need a AAAA record. If there is a native IPv6 address, = that's fine, it will use that, and the system might be best served if = the IPv6 connectivity is used. If there is a DNS64 AAAA record, the IPv4 = side will use an A record and the CLAT and PLAT, and the IPv6 side will = use the PLAT and the DNS64 address. > 3.1.3. Service Provider offering 464XLAT, without DNS64 The difference from the preceding section will be connectivity between = an IPv6-only device and an IPv4-only peer. In the previous section, the = IPv6 device will be unable to communicate with an IPv4-only peer, and = the dual stack device will use its IPv4 side, the CLAT, and the PLAT. > The major advantage of this scenario, using 464XLAT without DNS64, = is > that the service provider ensures that DNSSEC is never broken. Yes, but at the cost of IPv6-IPv4 connectivity. > 3.2. Known to Work Under Special Conditions >=20 > The scenarios in this category are known not to work unless "known to not work" I'll probably have more comments later, but I'm sending this much now. --Apple-Mail=_EE7756E6-37FB-47C1-9FCB-DE1D4614D84E 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+AFAlszw6IACgkQEhdRnd2G P+BrVBAApVPdJmpdXdVI2HRDSNl/JYxatBAEmZR1df0CT0wIcBAZ8VV3s9Vtast3 l3Klsjn8VPwx/00ySdYsUIq209b5iXyjOau8jwKwDhQhhYxX24VaEqNIIw+Ao5Wh Gucw/+U/TH55/Jo+JFeCusFEnUcxn5j8rKGe7rxAOsorJRfTDzOU0wSQLd+U2aAV qvbi30zoedoNABWjq/FihBgxQKc7a/AO9K2x1tvtPbsKBA+E04zWIXUoTKtkFveD kvPVx/xtvfHJAm2p+927Sx/thCbnweXP02Mr05xM7Wco1dhk4BGdZrBOB14ud2bN PlvqQ+7vbhKNcmInk7Zm53RNEj/jYt03h4Hn+rmguwwzhyqUXi+HO+9HufNSTzmU fXN0wIowquAUaIjiAtXFvUZ43nfxp9zEkIqJdxgqDdneIbQH6gr7Wjsiy11QWanw qGfd348zMP+wqQSym1q5YXPPlwhbdA2MerVL7KF9KGtlWb8n4G/CdLyqPKk+71Yk 5PmH3rome6uGQIkUUqXwE9FcS5jhXwXMZAiclldLnHUJycIDeSHwkuWzEH6Fhyhy pLsza7HDopkD4J1c5eNlZOJv0WcCnTuQx0Tn6lEYlaYzE4gK3uSt9gJqIUGz1cKV WXJAP8zWpOd9XbnUcD6I8eeyd4yxYwT3dbJT7XgJMoUjfXZpGaU= =oFmI -----END PGP SIGNATURE----- --Apple-Mail=_EE7756E6-37FB-47C1-9FCB-DE1D4614D84E-- From adegidio@telecentro.net.ar Wed Jun 27 11:43: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 7155A130E9A for ; Wed, 27 Jun 2018 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlfY1ZNf-sex for ; Wed, 27 Jun 2018 11:43:37 -0700 (PDT) Received: from tclmail6.telecentro.local (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58713130E00 for ; Wed, 27 Jun 2018 11:43:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tclmail6.telecentro.local (Postfix) with ESMTP id E55C83206F9B; Wed, 27 Jun 2018 15:43:34 -0300 (-03) Received: from tclmail6.telecentro.local ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rCzeAwlaW14L; Wed, 27 Jun 2018 15:43:34 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by tclmail6.telecentro.local (Postfix) with ESMTP id 71F3B32076FF; Wed, 27 Jun 2018 15:43:34 -0300 (-03) X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from tclmail6.telecentro.local ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id saMnnBrMNMGs; Wed, 27 Jun 2018 15:43:34 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by tclmail6.telecentro.local (Postfix) with ESMTP id 5A23C3206F9B; Wed, 27 Jun 2018 15:43:34 -0300 (-03) Date: Wed, 27 Jun 2018 15:43:33 -0300 (ART) From: Alejandro D'Egidio To: "v6ops@ietf.org list" Cc: Jordi Palet =?utf-8?Q?Mart=C3=ADnez?= , Fred Baker Message-ID: <1756348154.1454615.1530125013520.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_2009 (ZimbraWebClient - GC67 (Win)/8.8.8_GA_2009) Thread-Topic: draft-palet-v6ops-nat64-deployment-02 comments Thread-Index: TQwMKdDsYJvABs6Ck/M1Jqx1RIMlBQ== Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 18:46:33 -0000 Jordi, Fred, As a network operator I think this is a great work. It give to us the pos= sibility to have an IPv6 only access network where the need of IPv4 connect= ivity can be solved thanks to CLAT within the CPE, obviously we need also a= NAT64 as PLAT. Thanks for this work. Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025=C2=A0 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ----- Mensaje original ----- De: "Fred Baker" Para: "Jordi Palet Mart=C3=ADnez" , "v6ops@= ietf.org list" Enviados: Mi=C3=A9rcoles, 27 de Junio 2018 14:04:34 Asunto: draft-palet-v6ops-nat64-deployment-02 comments Chair comment: I am interested in making this draft a working group draft. = I think there is merit in it to do so. However, following our usual process= , I need agreement from the working group. Consider this a solicitation for= that. To do so, I'm looking for comments, supportive or otherwise, especia= lly from operators. To respond to Barbara's question that she raised with i= pv4aas, making it a working group document doesn't mean it's done, it means= it's a work item as opposed to a suggestion to the working group. The rest of this is sans hats. Thanks for your new draft. Let me say that I am increasingly hearing about = ISPs (cellular and broadband) that, in the words of one, "just don't want t= o allocate IPv4 addresses anymore", and are taking important steps toward t= urning IPv4 off within their networks in favor of IPv4 as a service. As you= know, this falls into a couple of categories - those that are willing to o= ffer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that = need to be able to somehow still put an IPv4 address into an A record (such= as a company like Lumix that uses Dynamic DNS Update and firewall hole-pun= ching to allow a residential user to access their surveillance system from = an Android/iPhone app) and use it to send a message to the IPv4 server. So = IMHO, this is an important draft, and it would be useful to get operator co= mment on it. I'm reviewing the draft. I'll bring up nits inline, and I may have some oth= er thoughts as well. > Abstract >=20 > This document describes how NAT64 and 464XLAT can be deployed in an > IPv6 operator (cellular and broadband) or enterprise network and the I suspect that this would read better as "IPv6 network, whether cellular IS= P, broadband ISP, or enterprise". > 1. Introduction > To avoid changes in both, the IPv6-only hosts and the IPv4-only > server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge > for the synthesis of AAAA records from the A records. I would disagree that NAT64 "requires" DNS64. NAT64 requires that the desti= nation IPv6 address contain an embedded IPv4 address. The source of that IP= v4-embedded IPv6 address is up to the system that sent the packet. A CLAT (= stateless translation as in RFC 7915) uses address synthesis with a PLAT tr= anslation prefix. MAP-T adds NAPT44 functionality to that with respect to t= he outbound IPv4 source address. A random IPv6 host accessing an IPv4-only = peer might use DNS64, and the AAAA records might simply exist in DNS contai= ning an IPv4-embedded IPv6 address. But the NAT64 function doesn't use, nor= does it require, DNS64. BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effective= ly NAPT) translator, and provides translation strictly at the IP layer. I s= uspect that is also a valid configuration, one that needs to be supported. = In the 464XLAT case, I think it falls out, but I'll have to think about MAP= -T. > 3. NAT64 Deployment Scenarios > Consequently, the perspective in this document is to broader those "broaden" > 3.1.2. Service Provider offering 464XLAT, with DNS64 Pictorial image of what I'm picturing: +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +--+--+ +--+-+ +------+ v6 +------+ | | | | +----+ | ,--+--. | ,--+--. |Dual | | IPv6 | / \ ,-+-. / \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ The dual stack device obviously has an IPv4 and an IPv6 address, and the IP= v4 side of it speaks through the CLAT. The IPv6 device has no IPv4 address.= The peer device is the thing the "dual stack" device connects to, and migh= t itself be dual stack or IPv4-only. In both cases, however, IPv4 access to= the peer device will go through the PLAT. When the IPv6 device wants to talk with the peer device, it will need a AAA= A record. In the dual stack case, that will contain a "usual" IPv6 address,= and connectivity will be IPv6 end to end; in the IPv4-only case, it will n= eed its IPv4 address embedded into the PLAT's translation prefix, which is = or is functionally equivalent to DNS64. When the dual stack device wants to talk with the Peer Device, its IPv4 sid= e will need an A record and the CLAT will do the address synthesis. Hence, = no need for DNS64, and no requirement for it if it exists. The IPv6 side wi= ll need a AAAA record. If there is a native IPv6 address, that's fine, it w= ill use that, and the system might be best served if the IPv6 connectivity = is used. If there is a DNS64 AAAA record, the IPv4 side will use an A recor= d and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DNS64 = address. > 3.1.3. Service Provider offering 464XLAT, without DNS64 The difference from the preceding section will be connectivity between an I= Pv6-only device and an IPv4-only peer. In the previous section, the IPv6 de= vice will be unable to communicate with an IPv4-only peer, and the dual sta= ck device will use its IPv4 side, the CLAT, and the PLAT. > The major advantage of this scenario, using 464XLAT without DNS64, is > that the service provider ensures that DNSSEC is never broken. Yes, but at the cost of IPv6-IPv4 connectivity. > 3.2. Known to Work Under Special Conditions >=20 > The scenarios in this category are known not to work unless "known to not work" I'll probably have more comments later, but I'm sending this much now. From nobody Wed Jun 27 11:53:02 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 8FE84130E00 for ; Wed, 27 Jun 2018 11:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw5qvttbyDqz for ; Wed, 27 Jun 2018 11:52:56 -0700 (PDT) Received: from tclmail6.telecentro.local (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FF6130DD7 for ; Wed, 27 Jun 2018 11:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tclmail6.telecentro.local (Postfix) with ESMTP id 27C4F3207572; Wed, 27 Jun 2018 15:52:54 -0300 (-03) Received: from tclmail6.telecentro.local ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LPlFOwKC7zmX; Wed, 27 Jun 2018 15:52:53 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by tclmail6.telecentro.local (Postfix) with ESMTP id 8F37A320142A; Wed, 27 Jun 2018 15:52:53 -0300 (-03) X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from tclmail6.telecentro.local ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ik9jQLMlgeBV; Wed, 27 Jun 2018 15:52:53 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by tclmail6.telecentro.local (Postfix) with ESMTP id 7B27F3208A3B; Wed, 27 Jun 2018 15:52:53 -0300 (-03) Date: Wed, 27 Jun 2018 15:52:53 -0300 (ART) From: Alejandro D'Egidio To: Fred Baker Cc: Jordi Palet =?utf-8?Q?Mart=C3=ADnez?= , "v6ops@ietf.org list" Message-ID: <645050768.1487885.1530125573454.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_2009 (ZimbraWebClient - GC67 (Win)/8.8.8_GA_2009) Thread-Topic: draft-palet-v6ops-nat64-deployment-02 comments Thread-Index: sVidAWVSC7PYOcceOtJrDcjijTYz1w== Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 18:53:00 -0000 Jordi, Fred, As a network operator I think this is a great work. It give to us the pos= sibility to have an IPv6 only access network where the need of IPv4 connect= ivity can be solved thanks to CLAT within the CPE, obviously we need also a= NAT64 as PLAT. Thanks for this work. Regards, ALEJANDRO D'EGIDIO=20 Jefe de Ingenier=C3=ADa de Backbone=20 F: +54 11 3977 1025=C2=A0 | M: +54 911 5794 1589=20 Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) ----- Mensaje original ----- De: "Fred Baker" Para: "Jordi Palet Mart=C3=ADnez" , "v6ops@= ietf.org list" Enviados: Mi=C3=A9rcoles, 27 de Junio 2018 14:04:34 Asunto: draft-palet-v6ops-nat64-deployment-02 comments Chair comment: I am interested in making this draft a working group draft. = I think there is merit in it to do so. However, following our usual process= , I need agreement from the working group. Consider this a solicitation for= that. To do so, I'm looking for comments, supportive or otherwise, especia= lly from operators. To respond to Barbara's question that she raised with i= pv4aas, making it a working group document doesn't mean it's done, it means= it's a work item as opposed to a suggestion to the working group. The rest of this is sans hats. Thanks for your new draft. Let me say that I am increasingly hearing about = ISPs (cellular and broadband) that, in the words of one, "just don't want t= o allocate IPv4 addresses anymore", and are taking important steps toward t= urning IPv4 off within their networks in favor of IPv4 as a service. As you= know, this falls into a couple of categories - those that are willing to o= ffer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that = need to be able to somehow still put an IPv4 address into an A record (such= as a company like Lumix that uses Dynamic DNS Update and firewall hole-pun= ching to allow a residential user to access their surveillance system from = an Android/iPhone app) and use it to send a message to the IPv4 server. So = IMHO, this is an important draft, and it would be useful to get operator co= mment on it. I'm reviewing the draft. I'll bring up nits inline, and I may have some oth= er thoughts as well. > Abstract >=20 > This document describes how NAT64 and 464XLAT can be deployed in an > IPv6 operator (cellular and broadband) or enterprise network and the I suspect that this would read better as "IPv6 network, whether cellular IS= P, broadband ISP, or enterprise". > 1. Introduction > To avoid changes in both, the IPv6-only hosts and the IPv4-only > server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge > for the synthesis of AAAA records from the A records. I would disagree that NAT64 "requires" DNS64. NAT64 requires that the desti= nation IPv6 address contain an embedded IPv4 address. The source of that IP= v4-embedded IPv6 address is up to the system that sent the packet. A CLAT (= stateless translation as in RFC 7915) uses address synthesis with a PLAT tr= anslation prefix. MAP-T adds NAPT44 functionality to that with respect to t= he outbound IPv4 source address. A random IPv6 host accessing an IPv4-only = peer might use DNS64, and the AAAA records might simply exist in DNS contai= ning an IPv4-embedded IPv6 address. But the NAT64 function doesn't use, nor= does it require, DNS64. BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effective= ly NAPT) translator, and provides translation strictly at the IP layer. I s= uspect that is also a valid configuration, one that needs to be supported. = In the 464XLAT case, I think it falls out, but I'll have to think about MAP= -T. > 3. NAT64 Deployment Scenarios > Consequently, the perspective in this document is to broader those "broaden" > 3.1.2. Service Provider offering 464XLAT, with DNS64 Pictorial image of what I'm picturing: +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +--+--+ +--+-+ +------+ v6 +------+ | | | | +----+ | ,--+--. | ,--+--. |Dual | | IPv6 | / \ ,-+-. / \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ The dual stack device obviously has an IPv4 and an IPv6 address, and the IP= v4 side of it speaks through the CLAT. The IPv6 device has no IPv4 address.= The peer device is the thing the "dual stack" device connects to, and migh= t itself be dual stack or IPv4-only. In both cases, however, IPv4 access to= the peer device will go through the PLAT. When the IPv6 device wants to talk with the peer device, it will need a AAA= A record. In the dual stack case, that will contain a "usual" IPv6 address,= and connectivity will be IPv6 end to end; in the IPv4-only case, it will n= eed its IPv4 address embedded into the PLAT's translation prefix, which is = or is functionally equivalent to DNS64. When the dual stack device wants to talk with the Peer Device, its IPv4 sid= e will need an A record and the CLAT will do the address synthesis. Hence, = no need for DNS64, and no requirement for it if it exists. The IPv6 side wi= ll need a AAAA record. If there is a native IPv6 address, that's fine, it w= ill use that, and the system might be best served if the IPv6 connectivity = is used. If there is a DNS64 AAAA record, the IPv4 side will use an A recor= d and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DNS64 = address. > 3.1.3. Service Provider offering 464XLAT, without DNS64 The difference from the preceding section will be connectivity between an I= Pv6-only device and an IPv4-only peer. In the previous section, the IPv6 de= vice will be unable to communicate with an IPv4-only peer, and the dual sta= ck device will use its IPv4 side, the CLAT, and the PLAT. > The major advantage of this scenario, using 464XLAT without DNS64, is > that the service provider ensures that DNSSEC is never broken. Yes, but at the cost of IPv6-IPv4 connectivity. > 3.2. Known to Work Under Special Conditions >=20 > The scenarios in this category are known not to work unless "known to not work" I'll probably have more comments later, but I'm sending this much now. From nobody Wed Jun 27 14:09: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 6B384130E2A for ; Wed, 27 Jun 2018 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-HhUjwULAu7 for ; Wed, 27 Jun 2018 14:09:07 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C59130E2F for ; Wed, 27 Jun 2018 14:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530133745; x=1530738545; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=y8wUxeaO fGpBF6V+6Ue+SvxZYlj1tVYmIzEC2DLF4uc=; b=gmflodBKZj/4enOg10pjfL0i HQF0Ieex/isOBp9zho8tGX5s5d0XpESt81wGupuXYaypZgEtnLYVOekFOb2XNCsj x/Ko0+TSdkNz/HyrI53dFhjzdV+vZY5NCWhhTbFBw6dXG19B9hfG2cPMIGQJmQGc kdYqkEqTegpnwgv/9s4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 27 Jun 2018 23:09:05 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 27 Jun 2018 23:09:04 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799203.msg for ; Wed, 27 Jun 2018 23:09:03 +0200 X-MDRemoteIP: 2001:470:1f09:495:c87f:b64f:f08f:9246 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 27 Jun 2018 23:09:03 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17165c862f=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Wed, 27 Jun 2018 23:08:36 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:09:11 -0000 Hi Fred, Thanks a lot ! Comments below in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: mi=C3=A9rcoles, 27 de junio de 2018, 19:05 Para: Jordi Palet Mart=C3=ADnez , "v6ops@ie= tf.org list" Asunto: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments Chair comment: I am interested in making this draft a working group dra= ft. I think there is merit in it to do so. However, following our usual pro= cess, I need agreement from the working group. Consider this a solicitation= for that. To do so, I'm looking for comments, supportive or otherwise, esp= ecially from operators. To respond to Barbara's question that she raised wi= th ipv4aas, making it a working group document doesn't mean it's done, it m= eans it's a work item as opposed to a suggestion to the working group. =20 The rest of this is sans hats. =20 Thanks for your new draft. Let me say that I am increasingly hearing ab= out ISPs (cellular and broadband) that, in the words of one, "just don't wa= nt to allocate IPv4 addresses anymore", and are taking important steps towa= rd turning IPv4 off within their networks in favor of IPv4 as a service. As= you know, this falls into a couple of categories - those that are willing = to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those t= hat need to be able to somehow still put an IPv4 address into an A record (= such as a company like Lumix that uses Dynamic DNS Update and firewall hole= -punching to allow a residential user to access their surveillance system f= rom an Android/iPhone app) and use it to send a message to the IPv4 server.= So IMHO, this is an important draft, and it would be useful to get operato= r comment on it. -> Agree and hopefully we can get a lot of contributions ... =20 I'm reviewing the draft. I'll bring up nits inline, and I may have some= other thoughts as well. =20 > Abstract >=20 > This document describes how NAT64 and 464XLAT can be deployed in a= n > IPv6 operator (cellular and broadband) or enterprise network and t= he =20 I suspect that this would read better as "IPv6 network, whether cellula= r ISP, broadband ISP, or enterprise". -> Perfect, thanks a lot. I'm already doing edits in my draft v03, so I don= 't miss any bit. =20 > 1. Introduction =20 > To avoid changes in both, the IPv6-only hosts and the IPv4-only > server, NAT64 requires also the use of a DNS64 ([RFC6147]), in cha= rge > for the synthesis of AAAA records from the A records. =20 I would disagree that NAT64 "requires" DNS64. NAT64 requires that the d= estination IPv6 address contain an embedded IPv4 address. The source of tha= t IPv4-embedded IPv6 address is up to the system that sent the packet. A CL= AT (stateless translation as in RFC 7915) uses address synthesis with a PLA= T translation prefix. MAP-T adds NAPT44 functionality to that with respect = to the outbound IPv4 source address. A random IPv6 host accessing an IPv4-o= nly peer might use DNS64, and the AAAA records might simply exist in DNS co= ntaining an IPv4-embedded IPv6 address. But the NAT64 function doesn't use,= nor does it require, DNS64. -> Agree, I took it from an equivalent text in the abstract of DNS64, but i= t makes sense to put it in reverse: "DNS64, is in charge of the synthesis of AAAA records from the A records, a= voiding changes in both, the IPv6-only hosts and the IPv4-only server, so t= hey can use a NAT64." =20 BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effec= tively NAPT) translator, and provides translation strictly at the IP layer.= I suspect that is also a valid configuration, one that needs to be support= ed. In the 464XLAT case, I think it falls out, but I'll have to think about= MAP-T. =20 > 3. NAT64 Deployment Scenarios =20 > Consequently, the perspective in this document is to broader those =20 "broaden" =20 > 3.1.2. Service Provider offering 464XLAT, with DNS64 =20 Pictorial image of what I'm picturing: =20 +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +--+--+ +--+-+ +------+ v6 +------+ | | | | +----+ | ,--+--. | ,--+--. |Dual | | IPv6 | / \ ,-+-. / \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ =20 The dual stack device obviously has an IPv4 and an IPv6 address, and th= e IPv4 side of it speaks through the CLAT. The IPv6 device has no IPv4 addr= ess. The peer device is the thing the "dual stack" device connects to, and = might itself be dual stack or IPv4-only. In both cases, however, IPv4 acces= s to the peer device will go through the PLAT. =20 When the IPv6 device wants to talk with the peer device, it will need a= AAAA record. In the dual stack case, that will contain a "usual" IPv6 addr= ess, and connectivity will be IPv6 end to end; in the IPv4-only case, it wi= ll need its IPv4 address embedded into the PLAT's translation prefix, which= is or is functionally equivalent to DNS64. =20 When the dual stack device wants to talk with the Peer Device, its IPv4= side will need an A record and the CLAT will do the address synthesis. Hen= ce, no need for DNS64, and no requirement for it if it exists. The IPv6 sid= e will need a AAAA record. If there is a native IPv6 address, that's fine, = it will use that, and the system might be best served if the IPv6 connectiv= ity is used. If there is a DNS64 AAAA record, the IPv4 side will use an A r= ecord and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DN= S64 address. -> Are you suggesting that I should make a more detailed description in eve= ry scenario, with more figures, etc. ? Or just in the 464XLAT case ? =20 > 3.1.3. Service Provider offering 464XLAT, without DNS64 =20 The difference from the preceding section will be connectivity between = an IPv6-only device and an IPv4-only peer. In the previous section, the IPv= 6 device will be unable to communicate with an IPv4-only peer, and the dual= stack device will use its IPv4 side, the CLAT, and the PLAT. -> Right, again, you feel I need to add text to explain that, so same as pr= evious question, having some extra text only for the 464XLAT cases? =20 > The major advantage of this scenario, using 464XLAT without DNS64,= is > that the service provider ensures that DNSSEC is never broken. =20 Yes, but at the cost of IPv6-IPv4 connectivity. =20 -> Yes, we are forcing one extra translation at the CE (which is the same a= s today happens with NAT44). I think if it is a choice of the operator to u= se DNS64 (and resolve a possible 1.7% - today - DNSSEC incidents), or make = its life easier by forcing some extra translations that of course, will kee= p decreasing as more IPv6 deployment happens in services/content providers.= If we take in consideration that 60% or so of the services more used (Yout= ube, Google, Facebook, etc.), area already IPv6 enabled, it means that in a= n ISP deploying IPv6, the number of "extra" translations at the CLAT will b= e really insignificant (and don't happen in the operator network, just in t= he CLAT) compared to the cost of breaking "some" DNSSEC. =20 > 3.2. Known to Work Under Special Conditions >=20 > The scenarios in this category are known not to work unless =20 "known to not work" =20 I'll probably have more comments later, but I'm sending this much now. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 27 18:56: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 CC6BE130E17 for ; Wed, 27 Jun 2018 18:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c99MaA569Her for ; Wed, 27 Jun 2018 18:56:03 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957C9130E79 for ; Wed, 27 Jun 2018 18:56:03 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id o202-v6so2353211vko.2 for ; Wed, 27 Jun 2018 18:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Rox7HIk2aK/RqrWQKD6ZbbqRXhav5UZMGMWHcaGnkxg=; b=Bz0RDQSVI1o4U4XFXiG2+0rUHhdNVr/UL6PRI3dO+KAcmxymrfVqz0ug9elKKSxN68 YrrHSjJWtUcZrHTbxOFVSLm9qRDG/vVZxj3r0e5GXkl3MEHG63pNi7xmrhew/+t0bt42 5rlUnPBHNVfJFI7vc59LKXxNMh+sMhdkNjz5hw0p2K2puAFRdbKOx2uuBEQYA6OJaZD5 0KlKrLgknfSb+f+cZc605N7a6BuQq2IFOXIzrc8xFBzCU6rJ2BLbWZatIx2AQ13TZkbj +UGsAvupgqAikfg7PveWdkXzbajlNFYVLtCnK1I1A4ut8C3pp1t1WyMNvxGM0mwr79AH RKQg== 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=Rox7HIk2aK/RqrWQKD6ZbbqRXhav5UZMGMWHcaGnkxg=; b=ujQ6lU/kyMt2MRbvxUeXuJFMquW2KV+kl2AIKvV8ejwvkakPnKsh5pF5FgiznIbtP2 StXcpKv5V219DJ5+w69ZfQygMw/b2PVFKk+mkADkpaE7l8c8BOmgFpELGQa4BFr31LAv aCZSkxbMTmIaA4hFlXJlF2n0fpQjKRZr5i+0fYRjKOLKVKcet5/0oxwDCunqWHzh3hSZ i1cQsy4q+Hk0uLj8GK0RMwfgX0FkHQPDWtBy3Q12SeZXFNXyzKe+BwZflVoA6q1BD/3e Vlm74Gcd6R1AB3lS23AxXe8dDDkWP/RqfnLa1qX1xm8Ghir0y3uCnP12Lm+lR1v1XW0T oaPQ== X-Gm-Message-State: APt69E1VfDXHE0XkAt26UJHXdD3i6tGi8W2enMR+N/qfxd1WGLeJn4i3 ECd78a5wL3L/m9QOWfbV3KQ= X-Google-Smtp-Source: AAOMgpe2ZwKc+i1Wx3N9Vt01e+qb5Yf0qU2M0RIk8wb4s177np05jP+Hv27Pva1eEwglPXq5NVvMkg== X-Received: by 2002:a1f:8dd4:: with SMTP id p203-v6mr5075076vkd.64.1530150962663; Wed, 27 Jun 2018 18:56:02 -0700 (PDT) Received: from [10.196.220.133] (41-197.icannmeeting.org. [199.91.197.41]) by smtp.gmail.com with ESMTPSA id j127-v6sm1607267vkd.23.2018.06.27.18.56.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 18:56:01 -0700 (PDT) From: Fred Baker Message-Id: <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FBD4F64B-F006-41DD-9026-A67FF3A92C40"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 27 Jun 2018 20:55:59 -0500 In-Reply-To: Cc: "v6ops@ietf.org list" To: JORDI PALET MARTINEZ References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:56:07 -0000 --Apple-Mail=_FBD4F64B-F006-41DD-9026-A67FF3A92C40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 27, 2018, at 4:08 PM, JORDI PALET MARTINEZ = wrote: >> 3.1.2. Service Provider offering 464XLAT, with DNS64 > -> Are you suggesting that I should make a more detailed description = in every scenario, with more figures, etc. ? Or just in the 464XLAT case = ? >=20 >> 3.1.3. Service Provider offering 464XLAT, without DNS64 >=20 > The difference from the preceding section will be connectivity = between an IPv6-only device and an IPv4-only peer. In the previous = section, the IPv6 device will be unable to communicate with an IPv4-only = peer, and the dual stack device will use its IPv4 side, the CLAT, and = the PLAT. >=20 > -> Right, again, you feel I need to add text to explain that, so same = as previous question, having some extra text only for the 464XLAT cases? >=20 >> The major advantage of this scenario, using 464XLAT without DNS64, = is >> that the service provider ensures that DNSSEC is never broken. >=20 > Yes, but at the cost of IPv6-IPv4 connectivity. I suppose in part I'm thinking out loud. But I do think it's important = to not trivialize the lack of connectivity in that last case, which I = think your current text does. Yes, DNSSEC doesn't work (doesn't validate = a signature, and probably doesn't *have* a signature) with a DNS64 IPv4 = embedded IPv6 Address. But it doesn't work without one either, because = in the case nothing works - there is no connectivity. It's a judgement = call, I suppose, but I think it's better to say it than let the = installing ISP discover it and wonder what happened. --Apple-Mail=_FBD4F64B-F006-41DD-9026-A67FF3A92C40 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+AFAls0QDAACgkQEhdRnd2G P+CBCg/9Hi+7reSaJh4y7VTkmy4m/QHmfKXnBWGzhgEJCzQG8MCTCiv76cMIKpYY FJZab1yYzK7KOBEdJqh+eHbHOud9dizx5Ih7YTKp404i/7UxRF5VKht3fv+5YxHX u7XFn0pcgZiKGf9Loq8sDGZBSo3mJ8WAIncdrtXgPICvlcGjGj5YPGYZsrleItzQ Q9UbLCAhlsfNBiDhbYzoMALGCGEl5BrVW2W/vSpl2nwVkeAxRBjzqL3BjRjg+d+I /aSJqiUmnufdz7ZSie2CiQURhSeT8dYaHsV5hZsdHfNayqZIDUugd2DQtg7Ijefc uNOzSEZUPkalfk+S1d7HIaE09nhi3ugPrM5ZNj1tKAq1aAJqtpodt35w2kwulwJS 1jfjP+VrFWrROpMJBrTt+a294a5LdrYeDhEwEoBJk2dbtjPl7RMG6sMB1ZJVbxdh gJFTFbQrqwau0QSTENMhaBIx0R8tVRIWLC9GiM5qt1dTmXBj7dBDEPYIKbQNd/80 6UTvfbwXqKNshGGlZu4KzQ9ZaTgGe0lwA5Rsv/DF0HOu/E4UZri1zSTyF/LUOTDx x/NA1Kg/wnKgqJeX1v6SQWtAFBxti2OSYQv8bymSg5qMQBJMi3/UqxyZcYruyNu5 iyt7EJQuwPaAwalxORFMHDYPFQTJJ6kpBzfH9vcbUu7fm8yBWp0= =0FFH -----END PGP SIGNATURE----- --Apple-Mail=_FBD4F64B-F006-41DD-9026-A67FF3A92C40-- From nobody Wed Jun 27 23:14: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 9018E130DF7 for ; Wed, 27 Jun 2018 23:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Xkvb7sYqVt for ; Wed, 27 Jun 2018 23:14:36 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF5B126F72 for ; Wed, 27 Jun 2018 23:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530166473; x=1530771273; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=BWctOGFFaZnWYfyjn/MoWOPKt5y/hMecmpyrBwPzDWY=; b=syHLyCjLfhUKq R8TWrsFKdvQ6aEp/qoj9PjOUGhnasu5rx1G9BJDk4h2k0ylHiCeiBRaGr4ZD8lgc usIC9Ki6EPUBVZ+IJ6AZJhdwbHWC6olLlQ5PDkYFVFmqQxUKH9014PefvxNi0u2w MCFq+bOjVKGA+Y7EXKqOl68quf5/ug= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 08:14:33 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 08:14:33 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799421.msg for ; Thu, 28 Jun 2018 08:14:32 +0200 X-MDRemoteIP: 2001:470:1f09:495:882e:62f3:2f4:887c X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 08:14:32 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 08:14:28 +0200 From: JORDI PALET MARTINEZ To: Fred Baker CC: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@gmail.com> In-Reply-To: <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 06:14:39 -0000 >> 3.1.2. Service Provider offering 464XLAT, with DNS64 > -> Are you suggesting that I should make a more detailed description in every scenario, with more figures, etc. ? Or just in the 464XLAT case ? > >> 3.1.3. Service Provider offering 464XLAT, without DNS64 > > The difference from the preceding section will be connectivity between an IPv6-only device and an IPv4-only peer. In the previous section, the IPv6 device will be unable to communicate with an IPv4-only peer, and the dual stack device will use its IPv4 side, the CLAT, and the PLAT. > > -> Right, again, you feel I need to add text to explain that, so same as previous question, having some extra text only for the 464XLAT cases? > >> The major advantage of this scenario, using 464XLAT without DNS64, is >> that the service provider ensures that DNSSEC is never broken. > > Yes, but at the cost of IPv6-IPv4 connectivity. I suppose in part I'm thinking out loud. But I do think it's important to not trivialize the lack of connectivity in that last case, which I think your current text does. Yes, DNSSEC doesn't work (doesn't validate a signature, and probably doesn't *have* a signature) with a DNS64 IPv4 embedded IPv6 Address. But it doesn't work without one either, because in the case nothing works - there is no connectivity. It's a judgement call, I suppose, but I think it's better to say it than let the installing ISP discover it and wonder what happened. -> Understood. I will improve the text to avoid that trivialization. However, I don't agree it doesn't works. What happens is that in that case, the connection in that case is done using the IPv4 stack of both peers (so the dual-stack host behind the CLAT CE, only see an "A" record, so naturally use only that one). ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Thu Jun 28 02:00:15 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 250AC130F07; Thu, 28 Jun 2018 02:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EVJ_0kYchNM; Thu, 28 Jun 2018 02:00:10 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70346130E0E; Thu, 28 Jun 2018 02:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530176405; x=1530781205; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type; bh=A10GFgImP76DO8iwnP603rG+btve4C1Q2Vv5HWUrgxU=; b=f8qQKdl2ZEoldXyx7yA6GGA7q3P5SdbgtY8RNpaIO+YaIUs7GCS08e4IytSYts RhtOc88WJb0F5M5f/1LxvvD/oDrTimVmUteD9a1Dtkjxm4nVHlqlu/0O6ERlj2dZ ClqWO0hwFYoXLPUthTWuNBNxPPoTvFbeIekb+MYkEccBo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 11:00:05 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 11:00:05 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799554.msg; Thu, 28 Jun 2018 11:00:04 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c2c:370f:f07a:986c X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 11:00:04 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 11:00:01 +0200 From: JORDI PALET MARTINEZ To: Erik Nygren , "v6ops@ietf.org list" , Tim Chown , <6man@ietf.org> Message-ID: <7AC12819-7F2A-4EB2-B8D4-C5420F604C5B@consulintel.es> Thread-Topic: draft-palet-v6ops-nat64-deployment (was DNS64 and DOH) - DNS64 support in draft-ietf-6man-rfc6434-bis Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3613028401_1394992468" Archived-At: Subject: [v6ops] draft-palet-v6ops-nat64-deployment (was DNS64 and DOH) - DNS64 support in draft-ietf-6man-rfc6434-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:00:14 -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_3613028401_1394992468 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi all, =20 I just recalled this issue that Erik brought to the DOH list during last me= eting, which by some reason, I totally forget until just now. =20 This is related to the last email exchange with Fred as well regarding pros= /cons of DNS64. =20 draft-ietf-doh-dns-over-https (v12) has the following on this matter: =20 3.1.=C2=A0 Non-requirements =C2=A0=C2=A0 o=C2=A0 Supporting network-specific DNS64 [RFC6147] =20 and =20 11.=C2=A0 Operational Considerations =C2=A0=C2=A0 Local policy considerations and similar factors mean different= DNS =C2=A0=C2=A0 servers may provide different results to the same query: for i= nstance =C2=A0=C2=A0 in split DNS configurations [RFC6950].=C2=A0 It logically foll= ows that the =C2=A0=C2=A0 server which is queried can influence the end result.=C2=A0 Th= erefore a =C2=A0=C2=A0 client's choice of DNS server may affect the responses it gets= to its =C2=A0=C2=A0 queries.=C2=A0 For example, in the case of DNS64 [RFC6147], th= e choice =C2=A0=C2=A0 could affect whether IPv6/IPv4 translation will work at all. =20 So, if DNS64 is being used, it may get broken not just by DoH, but I guess = also it may be happening in DNS over TLS, DNS over QUIC. I=E2=80=99m going = to check some of those cases and bring back a new version including some te= xt, if needed. =20 Obviously, the best solution will be to ensure that every host has support = for RFC7050/RFC7227/RFC6147, so they can do the DNS64 by themselves. This w= ill resolve all the issues of DNS64 I think. I=E2=80=99ve copied Tim on thi= s, may be is something that we haven=E2=80=99t realized till now, and shoul= d be considered in (draft-ietf-6man-rfc6434-bis) ? (copied 6man). Regards, Jordi =20 =20 =20 De: en nombre de Erik Nygren Fecha: domingo, 18 de marzo de 2018, 20:20 Para: , Jordi Palet Martinez , Le= e Howard Asunto: DNS64 and DOH =20 In reading through the dns-over-https draft I'm wondering if we should have= some better coverage of DNS64 which is becoming widely deployed in some mo= bile environments. (See https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00 for = some discussions which is on the v6ops agenda for this week.) Thinking some about this (and general IPv6-only deployments): * The section mentioning using IP literals as DOH service end-points may wi= sh to point out the risk that this may have challenges due to mixtures of I= Pv6-only, dual-stacked, and IPv4-only environments. * It would be good to add a section on how applications using DOH may wish = to handle "A" lookups in DNS64 environments. In particular, to do the DNS6= 4-synthesis and construction in the client when no AAAA record is available= and when a NAT64 prefix is available through a mechanism such as: RFC 7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Sy= nthesis, RFC 7225 - Discovering NAT64 IPv6 Prefixes Using the Port Contro= l Protocol (PCP) Doing the synthesis in the client seems preferable over trying to get the = server to do synthesis with the proper prefix in most scenarios, plus in ca= ses where the client is using the results directly this will get around som= e of the DNSSEC issues.=20 At least for mobile, not using DNS64 synthesis in the client will likely re= sult in this either breaking the client in NAT64 environments or causing so= mething lower in the stack to do the equivalent (a 464xlat CLAT on Android = or bump-in-the-API on iOS). =20 Erik =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3613028401_1394992468 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Hi all,

     

    I just recalled this issue that Erik brought to the DOH list during las= t meeting, which by some reason, I totally forget until just now.

     

    This is related to the last e= mail exchange with Fred as well regarding pros/cons of DNS64.

     

    draft-ietf-doh-dns-over-https (v12)= has the following on this matter:

     =

    3.1.=C2=A0 Non-requirements

    =C2=A0=C2= =A0 o=C2=A0 Supporting network-specific DNS64 [RFC6147]

     

    and

     

    11.=C2=A0 Operational Considerations

    <= p class=3DMsoNormal>=C2=A0=C2=A0 Local policy considerations and similar factors mean differen= t DNS

    =C2=A0=C2=A0 servers may provide different res= ults to the same query: for instance

    =C2=A0=C2=A0 in= split DNS configurations [RFC6950].=C2=A0 It logically follows that the

    =C2=A0=C2=A0 server which is queried can influence the= end result.=C2=A0 Therefore a

    =C2=A0=C2=A0 client's= choice of DNS server may affect the responses it gets to its

    =C2=A0=C2=A0 queries.=C2=A0 For example, in the case of DNS64 [RF= C6147], the choice

    =C2=A0=C2=A0 could affect whether= IPv6/IPv4 translation will work at all.

     =

    So, if DNS64 is being used, it may get broken not just b= y DoH, but I guess also it may be happening in DNS over TLS, DNS over QUIC.= I=E2=80=99m going to check some of those cases and bring back a new versio= n including some text, if needed.

     <= /span>

    Obviously, the best solution will be to ensure that every host = has support for RFC7050/RFC7227/RFC6147, so they can do the DNS64 by themse= lves. This will resolve all the issues of DNS64 I think. I=E2=80=99ve copie= d Tim on this, may be is something that we haven=E2=80=99t realized till no= w, and should be considered in (draft-ietf-6man-rfc6434-bis) ? (copied 6man= ).


    Regards,

    Jordi

     

     

     =

    De: <nygren@gmail.com> en nombre de Erik Nygren <= erik+ietf@nygren.org>
    Fecha: domingo, 18 de marzo de 2018, 20:= 20
    Para: <doh@ietf.org>, Jordi Palet Martinez <jordi.pal= et@consulintel.es>, Lee Howard <lee@asgard.org>
    Asunto: = DNS64 and DOH

     

    In reading through the dns-over-https draft I'm won= dering if we should have some better coverage of DNS64 which is becoming wi= dely deployed in some mobile environments.

    (See https://tools.ietf.org/html/draft-palet-v6o= ps-nat64-deployment-00 for some discussions which is on the v6ops agend= a for this week.)

    Thinking some about this (and general IPv6-only deployments):

    * The section mentionin= g using IP literals as DOH service end-points may wish to point out the ris= k that this may have challenges due to mixtures of IPv6-only, dual-stacked,= and IPv4-only environments.

    * It would be good to add a section on how app= lications using DOH may wish to handle "A" lookups in DNS64 envir= onments.  In particular, to do the DNS64-synthesis and construction in= the client when no AAAA record is available and when a NAT64 prefix is ava= ilable through a mechanism such as:
             &n= bsp; RFC 7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthesi= s,
               RFC 7225= - Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)

     Doing the = synthesis in the client seems preferable over trying to get the server to d= o synthesis with the proper prefix in most scenarios, plus in cases where t= he client is using the results directly this will get around some of the DN= SSEC issues.

    At least for mobile, not using DNS64 synthesis in the client = will likely result in this either breaking the client in NAT64 environments= or causing something lower in the stack to do the equivalent (a 464xlat CL= AT on Android or bump-in-the-API on iOS).

     

    <= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    &n= bsp;   Erik

     


    ********= **************************************
    IPv4 is over
    Are you ready for the new Internet ?
    http://www.consulintel.es
    The IPv6 Company

    This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

    --B_3613028401_1394992468-- From nobody Thu Jun 28 02:19:09 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 0185C130F2C; Thu, 28 Jun 2018 02:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAFePxw20d8y; Thu, 28 Jun 2018 02:18:57 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B272A1277D2; Thu, 28 Jun 2018 02:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1530177535; x=1530782335; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=IIw0Y7+BGGFutopyJItl7WxPVolVBIpSObs7zF22LeM=; b=VpKekwaXhkFbo n+o1+9DiDvRlpK3QhpSvQ7dpcdlr4sH+ODWeqokdyv9Z10sHAWAr1j+EnlXVzRqD mJOnItPX0PlvLjh5946RPWW8EcI3ImHW2gtSmS/tEYiIb+hKy3d2x3Gvn2iPa7eY VVUUDg3q1alVKkjYaZqaa8KhRCsSCg= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Thu, 28 Jun 2018 11:18:54 +0200 X-Spam-Processed: consulintel.es, Thu, 28 Jun 2018 11:18:54 +0200 Received: from [10.10.10.130] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799565.msg; Thu, 28 Jun 2018 11:18:54 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c2c:370f:f07a:986c X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 11:18:54 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1717c408a6=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 11:18:50 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: "v6ops@ietf.org list" , <6man@ietf.org> Message-ID: <66EAD1B7-DFC7-4A1A-BAB2-35F71FD58B6A@theipv6company.com> Thread-Topic: New Version Notification for draft-palet-v6ops-rfc6177-bis-00.txt References: <153017691613.14743.15012621303437153131.idtracker@ietfa.amsl.com> In-Reply-To: <153017691613.14743.15012621303437153131.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:19:00 -0000 Hi all, In the last months, following the discussions in 6man and v6ops, regarding = the prefix size for end-sites and subnets, I decided to work in a revision = of RFC6177 with the previous co-authors. Lea accepted the challenge (thanks= for that!), so we just posted a -bis for RFC6177: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6177-bis/ We will love comments, especially from those that have "heated the debate" = and will like to heard if we are missing anything to make it clearer. We believe that this document belongs to v6ops, so probably this is the bes= t list to comment about. An objective fact, unless we did the math's wrong, just to start: Math's show that even assuming 32 billion of humans (2^35), and assigning each of them 4 /48's, with a 50% routing efficiency, we can repeat that 2^10 times, so if average life span of each human is 100 years, and we don't recover back the /48's, we will be able to use IPv6 addressing space for over 100.000 years. Regards, Jordi =EF=BB=BF-----Mensaje original----- De: Fecha: jueves, 28 de junio de 2018, 11:08 Para: Jordi Palet , Jordi Palet Martinez , Rosalea G Roberts , Rosalea Roberts Asunto: New Version Notification for draft-palet-v6ops-rfc6177-bis-00.txt =20 A new version of I-D, draft-palet-v6ops-rfc6177-bis-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-rfc6177-bis Revision: 00 Title: IPv6 Address Assignment to End-Sites Document date: 2018-06-27 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= rfc6177-bis-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6= 177-bis/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-b= is-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -rfc6177-bis =20 =20 Abstract: The Regional Internet Registries (RIRs) policies, have different views regarding the recommendation of the prefix to be assigned to end-sites. However, all them allow up to a /48 without further justification and clearly state that the exact choice of how much address space should be assigned to end-sites is a decision of each operator. In fact, the operational community has recently developed a document with also covers this topic "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose". =20 This document reviews the architectural and operational considerations of end-site assignments, and reiterates that assignment policy and guidelines belong to the RIR community. This revision is being made to emphasize that IPv6 protocol evolution requires an ever increasing availability of subnets at the end-site and so, policy should reflect that assignment of a single subnet is no longer appropriate unless the recipient explicitly agrees to the limitations implied by such an assignment. =20 This document obsoletes RFC6177 (IPv6 Address Assignment to End Sites). =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 28 04:57: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 E8CC1130FE6 for ; Thu, 28 Jun 2018 04:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCj_8HRqsq5c for ; Thu, 28 Jun 2018 04:57:50 -0700 (PDT) Received: from tyo161.gate.nec.co.jp (tyo161.gate.nec.co.jp [114.179.232.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9CB130FF2 for ; Thu, 28 Jun 2018 04:57:34 -0700 (PDT) Received: from mailgate01.nec.co.jp ([114.179.233.122]) by tyo161.gate.nec.co.jp (8.15.1/8.15.1) with ESMTPS id w5SBvXSq024584 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 20:57:33 +0900 Received: from mailsv02.nec.co.jp (mailgate-v.nec.co.jp [10.204.236.94]) by mailgate01.nec.co.jp (8.15.1/8.15.1) with ESMTP id w5SBvX1O010661; Thu, 28 Jun 2018 20:57:33 +0900 Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv02.nec.co.jp (8.15.1/8.15.1) with ESMTP id w5SBumFd025171; Thu, 28 Jun 2018 20:57:33 +0900 Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.151] [10.38.151.151]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-1589865; Thu, 28 Jun 2018 20:57:04 +0900 Received: from BPXM24GP.gisp.nec.co.jp ([10.38.151.216]) by BPXC23GP.gisp.nec.co.jp ([10.38.151.151]) with mapi id 14.03.0319.002; Thu, 28 Jun 2018 20:57:04 +0900 From: Masanobu Kawashima To: =?gb2312?B?Sm9yZGkgUGFsZXQgTWFydKiqbmV6?= , "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments Thread-Index: AQHUDjkAzT/R9b3lJUCY0s+LPpm+hqR1iwTA Date: Thu, 28 Jun 2018 11:57:02 +0000 Message-ID: <81A3232BEF82944C8F23DB1CFE276F0F49615AAC@BPXM24GP.gisp.nec.co.jp> References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.141.178] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:57:53 -0000 DQpIaSBKb3JkaSwgDQoNCkkndmUgcmVhZCBhbGwgb2YgdGhpcyBkcmFmdC4gVGhpcyBpcyBhIGdy ZWF0IHdvcmsgYW5kIG5pY2UgZ3VpZGVsaW5lLiANCg0KSSdtIG5vdCBhIG5ldHdvcmsgb3BlcmF0 b3IsIGJ1dCBhcyBvbmUgb2YgQ0Ugcm91dGVyIHZlbmRvcnMsIA0KSSdsbCByZWNvbW1lbmQgb3Bl cmF0b3JzIHRvIHJlYWQgdGhpcyBkb2N1bWVudCBldmVuIGlmIGl0IGlzIHN0aWxsIGluZGl2aWR1 YWwgZHJhZnQuIA0KVGhpcyBkb2N1bWVudCB3aWxsIGhlbHAgdGhlbSBmb3IgdGhlaXIgZGVjaXNp b24sIGVzcGVjaWFsbHkgaWYgdGhleSBjb25zaWRlciANCk5BVDY0LzQ2NFhMQVQuIA0KDQpBbnl3 YXksIEkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4g DQpJIG1heSBpbnB1dCBzb21lIGluZm9ybWF0aW9uIHdoZW4gSSBnZXQgY29tbWVudHMgZnJvbSB0 aGVtLiANCg0KUmVnYXJkcywgDQpNYXNhbm9idSANCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09IA0KIE5FQyBQbGF0Zm9ybXMsIEx0ZC4gICAgICAgICAgICAgICAgIA0KIEtB V0FTSElNQSBNYXNhbm9idSAgICAgICAgICAgICAgICAgIA0KIGthd2FzaGltYW1AdnguanAubmVj LmNvbSAgICAgICAgICAgIA0KIGh0dHBzOi8vd3d3Lm5lY3BsYXRmb3Jtcy5jby5qcC9lbi8gIA0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IA0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBGcmVkIEJha2VyDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI4LCAyMDE4IDI6 MDUgQU0NCj4gVG86IEpvcmRpIFBhbGV0IE1hcnSoqm5leiA8am9yZGkucGFsZXRAdGhlaXB2NmNv bXBhbnkuY29tPjsgdjZvcHNAaWV0Zi5vcmcgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFt2Nm9wc10gZHJhZnQtcGFsZXQtdjZvcHMtbmF0NjQtZGVwbG95bWVudC0wMiBjb21tZW50 cw0KPiANCj4gQ2hhaXIgY29tbWVudDogSSBhbSBpbnRlcmVzdGVkIGluIG1ha2luZyB0aGlzIGRy YWZ0IGEgd29ya2luZyBncm91cCBkcmFmdC4gSSB0aGluayB0aGVyZSBpcyBtZXJpdCBpbiBpdCB0 byBkbyBzby4NCj4gSG93ZXZlciwgZm9sbG93aW5nIG91ciB1c3VhbCBwcm9jZXNzLCBJIG5lZWQg YWdyZWVtZW50IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAuIENvbnNpZGVyIHRoaXMgYSBzb2xpY2l0 YXRpb24gZm9yIHRoYXQuDQo+IFRvIGRvIHNvLCBJJ20gbG9va2luZyBmb3IgY29tbWVudHMsIHN1 cHBvcnRpdmUgb3Igb3RoZXJ3aXNlLCBlc3BlY2lhbGx5IGZyb20gb3BlcmF0b3JzLiBUbyByZXNw b25kIHRvIEJhcmJhcmEncyBxdWVzdGlvbg0KPiB0aGF0IHNoZSByYWlzZWQgd2l0aCBpcHY0YWFz LCBtYWtpbmcgaXQgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGRvZXNuJ3QgbWVhbiBpdCdzIGRv bmUsIGl0IG1lYW5zIGl0J3MgYSB3b3JrIGl0ZW0NCj4gYXMgb3Bwb3NlZCB0byBhIHN1Z2dlc3Rp b24gdG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQo+IA0KPiBUaGUgcmVzdCBvZiB0aGlzIGlzIHNhbnMg aGF0cy4NCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBuZXcgZHJhZnQuIExldCBtZSBzYXkgdGhhdCBJ IGFtIGluY3JlYXNpbmdseSBoZWFyaW5nIGFib3V0IElTUHMgKGNlbGx1bGFyIGFuZCBicm9hZGJh bmQpIHRoYXQsIGluDQo+IHRoZSB3b3JkcyBvZiBvbmUsICJqdXN0IGRvbid0IHdhbnQgdG8gYWxs b2NhdGUgSVB2NCBhZGRyZXNzZXMgYW55bW9yZSIsIGFuZCBhcmUgdGFraW5nIGltcG9ydGFudCBz dGVwcyB0b3dhcmQgdHVybmluZw0KPiBJUHY0IG9mZiB3aXRoaW4gdGhlaXIgbmV0d29ya3MgaW4g ZmF2b3Igb2YgSVB2NCBhcyBhIHNlcnZpY2UuIEFzIHlvdSBrbm93LCB0aGlzIGZhbGxzIGludG8g YSBjb3VwbGUgb2YgY2F0ZWdvcmllcw0KPiAtIHRob3NlIHRoYXQgYXJlIHdpbGxpbmcgdG8gb2Zm ZXIgYSBjbGllbnQtb25seSBJUHY0LW92ZXItSVB2NiBvciBJUHY0LWN1bS1JUHY2IHNlcnZpY2Us IGFuZCB0aG9zZSB0aGF0IG5lZWQgdG8gYmUNCj4gYWJsZSB0byBzb21laG93IHN0aWxsIHB1dCBh biBJUHY0IGFkZHJlc3MgaW50byBhbiBBIHJlY29yZCAoc3VjaCBhcyBhIGNvbXBhbnkgbGlrZSBM dW1peCB0aGF0IHVzZXMgRHluYW1pYyBETlMgVXBkYXRlDQo+IGFuZCBmaXJld2FsbCBob2xlLXB1 bmNoaW5nIHRvIGFsbG93IGEgcmVzaWRlbnRpYWwgdXNlciB0byBhY2Nlc3MgdGhlaXIgc3VydmVp bGxhbmNlIHN5c3RlbSBmcm9tIGFuIEFuZHJvaWQvaVBob25lDQo+IGFwcCkgYW5kIHVzZSBpdCB0 byBzZW5kIGEgbWVzc2FnZSB0byB0aGUgSVB2NCBzZXJ2ZXIuIFNvIElNSE8sIHRoaXMgaXMgYW4g aW1wb3J0YW50IGRyYWZ0LCBhbmQgaXQgd291bGQgYmUgdXNlZnVsDQo+IHRvIGdldCBvcGVyYXRv ciBjb21tZW50IG9uIGl0Lg0KPiANCj4gSSdtIHJldmlld2luZyB0aGUgZHJhZnQuIEknbGwgYnJp bmcgdXAgbml0cyBpbmxpbmUsIGFuZCBJIG1heSBoYXZlIHNvbWUgb3RoZXIgdGhvdWdodHMgYXMg d2VsbC4NCj4gDQo+ID4gQWJzdHJhY3QNCj4gPg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGhvdyBOQVQ2NCBhbmQgNDY0WExBVCBjYW4gYmUgZGVwbG95ZWQgaW4gYW4NCj4gPiAgICBJ UHY2IG9wZXJhdG9yIChjZWxsdWxhciBhbmQgYnJvYWRiYW5kKSBvciBlbnRlcnByaXNlIG5ldHdv cmsgYW5kIHRoZQ0KPiANCj4gSSBzdXNwZWN0IHRoYXQgdGhpcyB3b3VsZCByZWFkIGJldHRlciBh cyAiSVB2NiBuZXR3b3JrLCB3aGV0aGVyIGNlbGx1bGFyIElTUCwgYnJvYWRiYW5kIElTUCwgb3Ig ZW50ZXJwcmlzZSIuDQo+IA0KPiA+IDEuICBJbnRyb2R1Y3Rpb24NCj4gDQo+ID4gICAgVG8gYXZv aWQgY2hhbmdlcyBpbiBib3RoLCB0aGUgSVB2Ni1vbmx5IGhvc3RzIGFuZCB0aGUgSVB2NC1vbmx5 DQo+ID4gICAgc2VydmVyLCBOQVQ2NCByZXF1aXJlcyBhbHNvIHRoZSB1c2Ugb2YgYSBETlM2NCAo W1JGQzYxNDddKSwgaW4gY2hhcmdlDQo+ID4gICAgZm9yIHRoZSBzeW50aGVzaXMgb2YgQUFBQSBy ZWNvcmRzIGZyb20gdGhlIEEgcmVjb3Jkcy4NCj4gDQo+IEkgd291bGQgZGlzYWdyZWUgdGhhdCBO QVQ2NCAicmVxdWlyZXMiIEROUzY0LiBOQVQ2NCByZXF1aXJlcyB0aGF0IHRoZSBkZXN0aW5hdGlv biBJUHY2IGFkZHJlc3MgY29udGFpbiBhbiBlbWJlZGRlZA0KPiBJUHY0IGFkZHJlc3MuIFRoZSBz b3VyY2Ugb2YgdGhhdCBJUHY0LWVtYmVkZGVkIElQdjYgYWRkcmVzcyBpcyB1cCB0byB0aGUgc3lz dGVtIHRoYXQgc2VudCB0aGUgcGFja2V0LiBBIENMQVQgKHN0YXRlbGVzcw0KPiB0cmFuc2xhdGlv biBhcyBpbiBSRkMgNzkxNSkgdXNlcyBhZGRyZXNzIHN5bnRoZXNpcyB3aXRoIGEgUExBVCB0cmFu c2xhdGlvbiBwcmVmaXguIE1BUC1UIGFkZHMgTkFQVDQ0IGZ1bmN0aW9uYWxpdHkNCj4gdG8gdGhh dCB3aXRoIHJlc3BlY3QgdG8gdGhlIG91dGJvdW5kIElQdjQgc291cmNlIGFkZHJlc3MuIEEgcmFu ZG9tIElQdjYgaG9zdCBhY2Nlc3NpbmcgYW4gSVB2NC1vbmx5IHBlZXIgbWlnaHQgdXNlDQo+IERO UzY0LCBhbmQgdGhlIEFBQUEgcmVjb3JkcyBtaWdodCBzaW1wbHkgZXhpc3QgaW4gRE5TIGNvbnRh aW5pbmcgYW4gSVB2NC1lbWJlZGRlZCBJUHY2IGFkZHJlc3MuIEJ1dCB0aGUgTkFUNjQgZnVuY3Rp b24NCj4gZG9lc24ndCB1c2UsIG5vciBkb2VzIGl0IHJlcXVpcmUsIEROUzY0Lg0KPiANCj4gQlRX LCBTSUlULURDIG1ha2VzIHJhdGhlciBhIHBvaW50IHRoYXQgUkZDIDYxNDYgaXMgYSBwZXItc2Vz c2lvbiAoZWZmZWN0aXZlbHkgTkFQVCkgdHJhbnNsYXRvciwgYW5kIHByb3ZpZGVzIHRyYW5zbGF0 aW9uDQo+IHN0cmljdGx5IGF0IHRoZSBJUCBsYXllci4gSSBzdXNwZWN0IHRoYXQgaXMgYWxzbyBh IHZhbGlkIGNvbmZpZ3VyYXRpb24sIG9uZSB0aGF0IG5lZWRzIHRvIGJlIHN1cHBvcnRlZC4gSW4g dGhlIDQ2NFhMQVQNCj4gY2FzZSwgSSB0aGluayBpdCBmYWxscyBvdXQsIGJ1dCBJJ2xsIGhhdmUg dG8gdGhpbmsgYWJvdXQgTUFQLVQuDQo+IA0KPiA+IDMuICBOQVQ2NCBEZXBsb3ltZW50IFNjZW5h cmlvcw0KPiANCj4gPiAgICBDb25zZXF1ZW50bHksIHRoZSBwZXJzcGVjdGl2ZSBpbiB0aGlzIGRv Y3VtZW50IGlzIHRvIGJyb2FkZXIgdGhvc2UNCj4gDQo+ICJicm9hZGVuIg0KPiANCj4gPiAzLjEu Mi4gIFNlcnZpY2UgUHJvdmlkZXIgb2ZmZXJpbmcgNDY0WExBVCwgd2l0aCBETlM2NA0KPiANCj4g UGljdG9yaWFsIGltYWdlIG9mIHdoYXQgSSdtIHBpY3R1cmluZzoNCj4gDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0rICAgICAgICAgICAgICAgICstLS0tKw0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHxETlMgfCAgICAgKy0tLS0tKyAgICB8RE5TIHwNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICB8SVB2NnwgICAgIHxETlM2NHwgICAgfElQdjR8DQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tKy0rICAgICArLS0rLS0rICAgICstLSstKw0KPiAgICstLS0t LS0rIHY2ICstLS0tLS0rICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQo+ICAgfCAgICAg ICstLS0tKyAgICAgIHwgICAgLC0tKy0tLiAgICAgICB8ICAgICAgICwtLSstLS4NCj4gICB8RHVh bCAgfCAgICB8IElQdjYgfCAgIC8gICAgICAgXCAgICAsLSstLiAgICAvICAgICAgIFwNCj4gICB8 U3RhY2sgfCAgKy0rUm91dGVyKy0tKCAgSVB2NiAgICktLSggUExBVCktLSggIElQdjQgICApDQo+ ICAgfERldmljZXx2NHxDfCAgICAgIHwgICBcTmV0d29yay9gLiAgYC0tLScgICAgXE5ldHdvcmsv DQo+ICAgfCAgICAgICstLStMfCAgICAgIHwgICAgYC0tKy0tJyAgIGAuICAgICAgICAgL2AtLS0t LScNCj4gICArLS0tLS0tKyAgfEF8ICAgICAgfCAgICAgICB8ICAgICAgICBgKy0tLS0tLSsNCj4g ICAgICAgICAgICAgfFR8ICAgICAgfCAgICArLS0rLS0tKyAgICAgfCBQZWVyIHwNCj4gICAgICAg ICAgICAgKy0rLS0tLS0tKyAgICB8IElQdjYgfCAgICAgfERldmljZXwNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICB8RGV2aWNlfCAgICAgKy0tLS0tLSsNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tKw0KPiANCj4gVGhlIGR1YWwgc3RhY2sgZGV2aWNlIG9idmlvdXNseSBo YXMgYW4gSVB2NCBhbmQgYW4gSVB2NiBhZGRyZXNzLCBhbmQgdGhlIElQdjQgc2lkZSBvZiBpdCBz cGVha3MgdGhyb3VnaCB0aGUgQ0xBVC4NCj4gVGhlIElQdjYgZGV2aWNlIGhhcyBubyBJUHY0IGFk ZHJlc3MuIFRoZSBwZWVyIGRldmljZSBpcyB0aGUgdGhpbmcgdGhlICJkdWFsIHN0YWNrIiBkZXZp Y2UgY29ubmVjdHMgdG8sIGFuZCBtaWdodCBpdHNlbGYNCj4gYmUgZHVhbCBzdGFjayBvciBJUHY0 LW9ubHkuIEluIGJvdGggY2FzZXMsIGhvd2V2ZXIsIElQdjQgYWNjZXNzIHRvIHRoZSBwZWVyIGRl dmljZSB3aWxsIGdvIHRocm91Z2ggdGhlIFBMQVQuDQo+IA0KPiBXaGVuIHRoZSBJUHY2IGRldmlj ZSB3YW50cyB0byB0YWxrIHdpdGggdGhlIHBlZXIgZGV2aWNlLCBpdCB3aWxsIG5lZWQgYSBBQUFB IHJlY29yZC4gSW4gdGhlIGR1YWwgc3RhY2sgY2FzZSwgdGhhdA0KPiB3aWxsIGNvbnRhaW4gYSAi dXN1YWwiIElQdjYgYWRkcmVzcywgYW5kIGNvbm5lY3Rpdml0eSB3aWxsIGJlIElQdjYgZW5kIHRv IGVuZDsgaW4gdGhlIElQdjQtb25seSBjYXNlLCBpdCB3aWxsIG5lZWQNCj4gaXRzIElQdjQgYWRk cmVzcyBlbWJlZGRlZCBpbnRvIHRoZSBQTEFUJ3MgdHJhbnNsYXRpb24gcHJlZml4LCB3aGljaCBp cyBvciBpcyBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB0byBETlM2NC4NCj4gDQo+IFdoZW4gdGhl IGR1YWwgc3RhY2sgZGV2aWNlIHdhbnRzIHRvIHRhbGsgd2l0aCB0aGUgUGVlciBEZXZpY2UsIGl0 cyBJUHY0IHNpZGUgd2lsbCBuZWVkIGFuIEEgcmVjb3JkIGFuZCB0aGUgQ0xBVCB3aWxsDQo+IGRv IHRoZSBhZGRyZXNzIHN5bnRoZXNpcy4gSGVuY2UsIG5vIG5lZWQgZm9yIEROUzY0LCBhbmQgbm8g cmVxdWlyZW1lbnQgZm9yIGl0IGlmIGl0IGV4aXN0cy4gVGhlIElQdjYgc2lkZSB3aWxsIG5lZWQN Cj4gYSBBQUFBIHJlY29yZC4gSWYgdGhlcmUgaXMgYSBuYXRpdmUgSVB2NiBhZGRyZXNzLCB0aGF0 J3MgZmluZSwgaXQgd2lsbCB1c2UgdGhhdCwgYW5kIHRoZSBzeXN0ZW0gbWlnaHQgYmUgYmVzdCBz ZXJ2ZWQNCj4gaWYgdGhlIElQdjYgY29ubmVjdGl2aXR5IGlzIHVzZWQuIElmIHRoZXJlIGlzIGEg RE5TNjQgQUFBQSByZWNvcmQsIHRoZSBJUHY0IHNpZGUgd2lsbCB1c2UgYW4gQSByZWNvcmQgYW5k IHRoZSBDTEFUDQo+IGFuZCBQTEFULCBhbmQgdGhlIElQdjYgc2lkZSB3aWxsIHVzZSB0aGUgUExB VCBhbmQgdGhlIEROUzY0IGFkZHJlc3MuDQo+IA0KPiA+IDMuMS4zLiAgU2VydmljZSBQcm92aWRl ciBvZmZlcmluZyA0NjRYTEFULCB3aXRob3V0IEROUzY0DQo+IA0KPiBUaGUgZGlmZmVyZW5jZSBm cm9tIHRoZSBwcmVjZWRpbmcgc2VjdGlvbiB3aWxsIGJlIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGFu IElQdjYtb25seSBkZXZpY2UgYW5kIGFuIElQdjQtb25seSBwZWVyLg0KPiBJbiB0aGUgcHJldmlv dXMgc2VjdGlvbiwgdGhlIElQdjYgZGV2aWNlIHdpbGwgYmUgdW5hYmxlIHRvIGNvbW11bmljYXRl IHdpdGggYW4gSVB2NC1vbmx5IHBlZXIsIGFuZCB0aGUgZHVhbCBzdGFjaw0KPiBkZXZpY2Ugd2ls bCB1c2UgaXRzIElQdjQgc2lkZSwgdGhlIENMQVQsIGFuZCB0aGUgUExBVC4NCj4gDQo+ID4gICAg VGhlIG1ham9yIGFkdmFudGFnZSBvZiB0aGlzIHNjZW5hcmlvLCB1c2luZyA0NjRYTEFUIHdpdGhv dXQgRE5TNjQsIGlzDQo+ID4gICAgdGhhdCB0aGUgc2VydmljZSBwcm92aWRlciBlbnN1cmVzIHRo YXQgRE5TU0VDIGlzIG5ldmVyIGJyb2tlbi4NCj4gDQo+IFllcywgYnV0IGF0IHRoZSBjb3N0IG9m IElQdjYtSVB2NCBjb25uZWN0aXZpdHkuDQo+IA0KPiA+IDMuMi4gIEtub3duIHRvIFdvcmsgVW5k ZXIgU3BlY2lhbCBDb25kaXRpb25zDQo+ID4NCj4gPiAgICBUaGUgc2NlbmFyaW9zIGluIHRoaXMg Y2F0ZWdvcnkgYXJlIGtub3duIG5vdCB0byB3b3JrIHVubGVzcw0KPiANCj4gImtub3duIHRvIG5v dCB3b3JrIg0KPiANCj4gSSdsbCBwcm9iYWJseSBoYXZlIG1vcmUgY29tbWVudHMgbGF0ZXIsIGJ1 dCBJJ20gc2VuZGluZyB0aGlzIG11Y2ggbm93Lg0K From nobody Thu Jun 28 05:16: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 47AC213101B for ; Thu, 28 Jun 2018 05:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1IRceXmyWir for ; Thu, 28 Jun 2018 05:16:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F957129619 for ; Thu, 28 Jun 2018 05:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530188176; x=1530792976; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=JF8jxoqa nj7D7aUBBEsg0vIfxapgbYJlmcHFIV46920=; b=tamC5vg+BLkqnfpOl1558pd8 Q79Dh1swHLrzzq3Cajp0qFXLFnhuGSp4aIcQWnsQPv3B58JCPFxgpanm16N8KWYa qdRHPp261/T7fbN0Au3q4/8D9v0prXPslvIdd2cBW4fGdV1ovBJXM7XXFMOxGJIe Of2PnKQKVMUYzsYv9P8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 14:16:16 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 14:16:16 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799677.msg for ; Thu, 28 Jun 2018 14:16:15 +0200 X-MDRemoteIP: 2001:470:1f09:495:c19:c45c:ade4:c077 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 14:16:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 14:16:13 +0200 From: JORDI PALET MARTINEZ To: Masanobu Kawashima , "v6ops@ietf.org list" Message-ID: <87D2608E-F092-4D2E-87FB-0D773D7F80B7@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <81A3232BEF82944C8F23DB1CFE276F0F49615AAC@BPXM24GP.gisp.nec.co.jp> In-Reply-To: <81A3232BEF82944C8F23DB1CFE276F0F49615AAC@BPXM24GP.gisp.nec.co.jp> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 12:16:22 -0000 Hi Masanobu, Thanks for this. It will be nice if you can circulate the link around NOGs, so we can get mo= re inputs on it. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Masanobu Kawashima Fecha: jueves, 28 de junio de 2018, 13:58 Para: Jordi Palet Mart=C3=ADnez , "v6ops@ie= tf.org list" Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments =20 Hi Jordi,=20 =20 I've read all of this draft. This is a great work and nice guideline.= =20 =20 I'm not a network operator, but as one of CE router vendors,=20 I'll recommend operators to read this document even if it is still indi= vidual draft.=20 This document will help them for their decision, especially if they con= sider=20 NAT64/464XLAT.=20 =20 Anyway, I support this document as a working group document.=20 I may input some information when I get comments from them.=20 =20 Regards,=20 Masanobu=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 NEC Platforms, Ltd. =20 KAWASHIMA Masanobu =20 kawashimam@vx.jp.nec.com =20 https://www.necplatforms.co.jp/en/ =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 =20 > -----Original Message----- > From: v6ops On Behalf Of Fred Baker > Sent: Thursday, June 28, 2018 2:05 AM > To: Jordi Palet Mart=C3=ADnez ; v6ops= @ietf.org list > Subject: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments >=20 > Chair comment: I am interested in making this draft a working group d= raft. I think there is merit in it to do so. > However, following our usual process, I need agreement from the worki= ng group. Consider this a solicitation for that. > To do so, I'm looking for comments, supportive or otherwise, especial= ly from operators. To respond to Barbara's question > that she raised with ipv4aas, making it a working group document does= n't mean it's done, it means it's a work item > as opposed to a suggestion to the working group. >=20 > The rest of this is sans hats. >=20 > Thanks for your new draft. Let me say that I am increasingly hearing = about ISPs (cellular and broadband) that, in > the words of one, "just don't want to allocate IPv4 addresses anymore= ", and are taking important steps toward turning > IPv4 off within their networks in favor of IPv4 as a service. As you = know, this falls into a couple of categories > - those that are willing to offer a client-only IPv4-over-IPv6 or IPv= 4-cum-IPv6 service, and those that need to be > able to somehow still put an IPv4 address into an A record (such as a= company like Lumix that uses Dynamic DNS Update > and firewall hole-punching to allow a residential user to access thei= r surveillance system from an Android/iPhone > app) and use it to send a message to the IPv4 server. So IMHO, this i= s an important draft, and it would be useful > to get operator comment on it. >=20 > I'm reviewing the draft. I'll bring up nits inline, and I may have so= me other thoughts as well. >=20 > > Abstract > > > > This document describes how NAT64 and 464XLAT can be deployed in= an > > IPv6 operator (cellular and broadband) or enterprise network and= the >=20 > I suspect that this would read better as "IPv6 network, whether cellu= lar ISP, broadband ISP, or enterprise". >=20 > > 1. Introduction >=20 > > To avoid changes in both, the IPv6-only hosts and the IPv4-only > > server, NAT64 requires also the use of a DNS64 ([RFC6147]), in c= harge > > for the synthesis of AAAA records from the A records. >=20 > I would disagree that NAT64 "requires" DNS64. NAT64 requires that the= destination IPv6 address contain an embedded > IPv4 address. The source of that IPv4-embedded IPv6 address is up to = the system that sent the packet. A CLAT (stateless > translation as in RFC 7915) uses address synthesis with a PLAT transl= ation prefix. MAP-T adds NAPT44 functionality > to that with respect to the outbound IPv4 source address. A random IP= v6 host accessing an IPv4-only peer might use > DNS64, and the AAAA records might simply exist in DNS containing an I= Pv4-embedded IPv6 address. But the NAT64 function > doesn't use, nor does it require, DNS64. >=20 > BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (eff= ectively NAPT) translator, and provides translation > strictly at the IP layer. I suspect that is also a valid configuratio= n, one that needs to be supported. In the 464XLAT > case, I think it falls out, but I'll have to think about MAP-T. >=20 > > 3. NAT64 Deployment Scenarios >=20 > > Consequently, the perspective in this document is to broader tho= se >=20 > "broaden" >=20 > > 3.1.2. Service Provider offering 464XLAT, with DNS64 >=20 > Pictorial image of what I'm picturing: >=20 > +----+ +----+ > |DNS | +-----+ |DNS | > |IPv6| |DNS64| |IPv4| > +--+-+ +--+--+ +--+-+ > +------+ v6 +------+ | | | > | +----+ | ,--+--. | ,--+--. > |Dual | | IPv6 | / \ ,-+-. / \ > |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) > |Device|v4|C| | \Network/`. `---' \Network/ > | +--+L| | `--+--' `. /`-----' > +------+ |A| | | `+------+ > |T| | +--+---+ | Peer | > +-+------+ | IPv6 | |Device| > |Device| +------+ > +------+ >=20 > The dual stack device obviously has an IPv4 and an IPv6 address, and = the IPv4 side of it speaks through the CLAT. > The IPv6 device has no IPv4 address. The peer device is the thing the= "dual stack" device connects to, and might itself > be dual stack or IPv4-only. In both cases, however, IPv4 access to th= e peer device will go through the PLAT. >=20 > When the IPv6 device wants to talk with the peer device, it will need= a AAAA record. In the dual stack case, that > will contain a "usual" IPv6 address, and connectivity will be IPv6 en= d to end; in the IPv4-only case, it will need > its IPv4 address embedded into the PLAT's translation prefix, which i= s or is functionally equivalent to DNS64. >=20 > When the dual stack device wants to talk with the Peer Device, its IP= v4 side will need an A record and the CLAT will > do the address synthesis. Hence, no need for DNS64, and no requiremen= t for it if it exists. The IPv6 side will need > a AAAA record. If there is a native IPv6 address, that's fine, it wil= l use that, and the system might be best served > if the IPv6 connectivity is used. If there is a DNS64 AAAA record, th= e IPv4 side will use an A record and the CLAT > and PLAT, and the IPv6 side will use the PLAT and the DNS64 address. >=20 > > 3.1.3. Service Provider offering 464XLAT, without DNS64 >=20 > The difference from the preceding section will be connectivity betwee= n an IPv6-only device and an IPv4-only peer. > In the previous section, the IPv6 device will be unable to communicat= e with an IPv4-only peer, and the dual stack > device will use its IPv4 side, the CLAT, and the PLAT. >=20 > > The major advantage of this scenario, using 464XLAT without DNS6= 4, is > > that the service provider ensures that DNSSEC is never broken. >=20 > Yes, but at the cost of IPv6-IPv4 connectivity. >=20 > > 3.2. Known to Work Under Special Conditions > > > > The scenarios in this category are known not to work unless >=20 > "known to not work" >=20 > I'll probably have more comments later, but I'm sending this much now= . _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 28 05:24: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 20309130F8A for ; Thu, 28 Jun 2018 05:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XmFNmWGqi1SJ for ; Thu, 28 Jun 2018 05:24:00 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0BB129619 for ; Thu, 28 Jun 2018 05:24:00 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id v16-v6so58554vkd.6 for ; Thu, 28 Jun 2018 05:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P6qnYZI3VqM2rjCyH3m9jHSShtFqQkl8nysAPpbribc=; b=VmX1Il1gb8UUwFguER0mD/U9WOHNwvw9ll3XcMdEl659hNeb0f38IXIhFdBRv21BIy dzaIORplzf79oSIhSG7CH7WlDAY+M8VxQnxfEr1QAIgixKHyhBm+ostWPWRoY6Mwi6Rt P46BQGSQYBKfSgmGJrO35BEcYW2RkiPIMfCi7ut0l3880EZxq0JV/1ICUbxDwE87P3uY M5D4fqZCm97HYxT2wgHZkA9+UE2cx9o1sGD27COmam6E/IcS2v+9pbupsdAvMygUm2xf dx0d8WLY4RdLYpz/1Nv4I8DS7RQ4/yT7AZroc7ENwFiG+FETOG/3dsrJxaUvMnVFAWx8 PxbQ== 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=P6qnYZI3VqM2rjCyH3m9jHSShtFqQkl8nysAPpbribc=; b=q8i6VcpSL0mRiUxg2hmxYCQx6sodaVOkdTp0vYMzJgtInGt3DQTUne4ySjSqQTbOuQ 6c00205h5HwNPMgP7I2dUlqzfVlfthuOSrrjN+ufetkFKayGW7yXyzhA1jXRJ4+vFNth i0ExiqLAbPQWitxjF6UNio0ZnvrJZ2SkiNm69EexuJgSQkXP6qYVAGMYTZ3yZhDfqH6j biwSTf6Wt3990ao9WqY+peaubw6oOauhlLGIceOyPVaxbO2qmzeASAbpOOa/iSHZEWtn TnMgT5TTjBV+qioVWOMqPKB9S4iC3sVzErM8aMiTKqQ9LXz/ny4AnPBpQm3WWx3yO2in +leg== X-Gm-Message-State: APt69E0azEPSU7E9alORKE1MnXP0vqevAHRA2bE1wBTGxdPyxbjXW5q3 5itQlJa8a8cDTXW8rdCin+7yCfM9 X-Google-Smtp-Source: AAOMgpeMb4mFsxX9OjcG5eWWnXN9e+OcC9kPmO9F4vN8uZEvMntsPEJ+4TFKpNUWOe4mzuAlWmJBxw== X-Received: by 2002:a1f:7c4:: with SMTP id 187-v6mr6002247vkh.60.1530188639351; Thu, 28 Jun 2018 05:23:59 -0700 (PDT) Received: from [10.196.220.133] (41-197.icannmeeting.org. [199.91.197.41]) by smtp.gmail.com with ESMTPSA id o78-v6sm1747845vke.52.2018.06.28.05.23.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 05:23:58 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_96BCE022-7423-4C51-8F01-4095D76D7B93"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 28 Jun 2018 07:23:56 -0500 In-Reply-To: Cc: "v6ops@ietf.org list" To: JORDI PALET MARTINEZ References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 12:24:03 -0000 --Apple-Mail=_96BCE022-7423-4C51-8F01-4095D76D7B93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 28, 2018, at 1:14 AM, JORDI PALET MARTINEZ = wrote: >>>> The major advantage of this scenario, using 464XLAT without DNS64, = is >>>> that the service provider ensures that DNSSEC is never broken. >>>=20 >>> Yes, but at the cost of IPv6-IPv4 connectivity. >>=20 >> I suppose in part I'm thinking out loud. But I do think it's = important to not trivialize the lack of connectivity in that last case, = which I think your current text does. Yes, DNSSEC doesn't work (doesn't = validate a signature, and probably doesn't *have* a signature) with a = DNS64 IPv4 embedded IPv6 Address. But it doesn't work without one = either, because in the case nothing works - there is no connectivity. = It's a judgement call, I suppose, but I think it's better to say it than = let the installing ISP discover it and wonder what happened. >=20 > -> Understood. I will improve the text to avoid that trivialization. = However, I don't agree it doesn't works. What happens is that in that = case, the connection in that case is done using the IPv4 stack of both = peers (so the dual-stack host behind the CLAT CE, only see an "A" = record, so naturally use only that one). For the dual stack host behind the CLAT, yes. For the IPv6-only host, = there is either no connectivity to an IPv4-only host, or it goes through = the PLAT and DNSSEC is broken. There remains no connectivity using the = signed DNSSEC A record, because the IPv6-only host isn't using it. --Apple-Mail=_96BCE022-7423-4C51-8F01-4095D76D7B93 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+AFAls001wACgkQEhdRnd2G P+ANoBAAv8/CluDovGTJ6w3G0TGBu6qq0nwP7DIQ+zZ8S75zxQ0rl/W2CcAHsXv1 mS+hzFTs8kc8Rb3ROnDBHo1OOJFX/F9aMlO8OWf9IViHYV5vKFmdJsFj/KN7VIBa /tsYAkbMtrcj48SvHUUefZNdPljTZGvo4QDaE3KZlod8UDB73IAPYAvBdEVAQA8F FTKqQ10eWvwtGAHvKvp4RXH2dupK37uDmkGLx6T6ftRe3sfduHYi1vSy5Pr9hHUi cvwXqhc/G3zpR06zdRG6V4FumAVZiZfrw7QkrNfWJygVL0C4giaPTQh8etC0k6Bs 9eaBCreD+wNtDkqdg/t05a8M8c4doR6ps0vvBT7yM7RAdEhu9IPbPKGCZqkb5yiS oFRZD8VWwg3s2EZhjSVM7waLHSmeCnYy7estvOohlKZDvMC1zAlKEPL7DNv+Mv/D MZWTcb+xzppoO/GFulPWRxbEYlw0wK91VlP/N6Zf2DFhyAd+aW3KyPgQ4aypF1Rh 79sWpDbH78NeoBhX9zX2l6KKxsoDB5AndikYjetteJVc9Du4W5rKdBk09Hlw10e/ 5sD8zkVrmWeguBO2S2LD+d91HnaPycf1NPAzJHwljjCQxTDRr6fs992gxri6SlNp 16ZBO4aqA3zwOxTMQt3criqmMbYlYPK41fK55919r/BZZkbCqTw= =lZi5 -----END PGP SIGNATURE----- --Apple-Mail=_96BCE022-7423-4C51-8F01-4095D76D7B93-- From nobody Thu Jun 28 05:30: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 3C08B130FBE for ; Thu, 28 Jun 2018 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHXyJIQrxEgG for ; Thu, 28 Jun 2018 05:30:54 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5648D130F93 for ; Thu, 28 Jun 2018 05:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530189051; x=1530793851; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=ILiuC2lYyBkyIb1LQryKsbfu3bK7cRHCL0Mud+ln00Y=; b=YaSkobdMaPWMv a2UL4YBTWsdIHzWOB9j+CEwZVYVMVWUmRdz7qu6TdkJjgKPWzuZ+MwcVQSG093// UFMBb4W8I+W0yL7X8DKSwFi1rT/HfwBx48/CtJDlToO8Ld4udVYQxwRCJEIq+cqj Gd1eDcZFUl8kGPxEVvr6MnDYOt6NtE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 14:30:51 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 14:30:51 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005799694.msg for ; Thu, 28 Jun 2018 14:30:50 +0200 X-MDRemoteIP: 2001:470:1f09:495:c19:c45c:ade4:c077 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 14:30:50 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 14:30:50 +0200 From: JORDI PALET MARTINEZ To: Fred Baker CC: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@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] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 12:30:57 -0000 Do you think it makes sense today for a smart OS or app provider, knowing t= hat that app need to talk to IPv4-only hosts, to make that app or OS, IPv6-= only? If I'm on their feet, will only make the app or OS IPv6-only once I'm 100% = sure that what the peer I need to speak, is also IPv6-ready. And by the way, this will only make sense when that OS or app provider know= s for sure that their customers will get also IPv6 from their ISPs. Or I'm missing something? So what I'm saying is that supporting IPv6-only hosts is not making sense f= or now, and even if that is supported, that the ISP offers DNS64, all will = get broken if the user changes the DNS servers ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fred Baker Fecha: jueves, 28 de junio de 2018, 14:24 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments =20 =20 On Jun 28, 2018, at 1:14 AM, JORDI PALET MARTINEZ wrote: >>>> The major advantage of this scenario, using 464XLAT without DNS64= , is >>>> that the service provider ensures that DNSSEC is never broken. >>>=20 >>> Yes, but at the cost of IPv6-IPv4 connectivity. >>=20 >> I suppose in part I'm thinking out loud. But I do think it's impo= rtant to not trivialize the lack of connectivity in that last case, which I= think your current text does. Yes, DNSSEC doesn't work (doesn't validate a= signature, and probably doesn't *have* a signature) with a DNS64 IPv4 embe= dded IPv6 Address. But it doesn't work without one either, because in the c= ase nothing works - there is no connectivity. It's a judgement call, I supp= ose, but I think it's better to say it than let the installing ISP discover= it and wonder what happened. >=20 > -> Understood. I will improve the text to avoid that trivialization. = However, I don't agree it doesn't works. What happens is that in that case,= the connection in that case is done using the IPv4 stack of both peers (so= the dual-stack host behind the CLAT CE, only see an "A" record, so natural= ly use only that one). =20 For the dual stack host behind the CLAT, yes. For the IPv6-only host, t= here is either no connectivity to an IPv4-only host, or it goes through the= PLAT and DNSSEC is broken. There remains no connectivity using the signed = DNSSEC A record, because the IPv6-only host isn't using it. =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Jun 28 05:40: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 3A7E4130EFC for ; Thu, 28 Jun 2018 05:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0qN-NGUk2vOe for ; Thu, 28 Jun 2018 05:40:17 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68201130F91 for ; Thu, 28 Jun 2018 05:40:17 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id g18-v6so716149uak.0 for ; Thu, 28 Jun 2018 05:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UPuIpkZwyImvkSJjQq9ZythWlIJ1so8lwN0qvpJbPfs=; b=lczCTKkzFg7CmVfzwJ0gGvU6ZMhcq8QVAwuniH+vnsB2rbaDJ4ukwVgpeR17At4Hvl uxgcYGMiia6a534zXLdbt9nMVhtaRTc0NAp7Oqv3F0cnpKehmO0Iko0TLjwMwQBNCy9L ysHAgqXCuxSyaZfoyRRJgcQskJpt5Hrs8quiGN7YdnQN364YQ8vxfnVjPy/Hi/A+5jOF hjt6Zwxn/HIF0Q3octJPxUrqkaBzN18C8itBKM2z+Y+U8KZmdKN9wQ2F5isNfNGch9E8 Y7mSw51mqbhmtLpUKj3m8AE24W/buAqO0rWmse8bvAbHbvRe40I/oyyTMsyQepV0S8HH mUyA== 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=UPuIpkZwyImvkSJjQq9ZythWlIJ1so8lwN0qvpJbPfs=; b=X7NRR6cZXoVSEbHU1jEdTf/kZc7a+pqN9UQcq/8+lb95YrV4+5Wg3xfrzmCwXuU7t6 l+IpraO8qDs21TCzP7b+sP7d/w4Dmjj0ZO3XTcQWiX91YojsweXQoUpDTl/HcXg2Chx8 lGJQesmvGY1O46KAlMpRaV5/q/Sjgu6+aK4iO9tkAdIaMh8iA2RWPjsRiZj7WpQD+Gso PaVk8vyfN1zg7PoIa+f3e8X1eFwV6g2sKlKfgBo0UT2bcvwCK78tpLuQz8Y1MY8nUBit VtdpMnRGIHa1KRzVX0+FLHS/pHBmaoFZ/81V44jbUP04GvIy7qcv1vmeN+mj52S/L1iJ RScw== X-Gm-Message-State: APt69E3UZZawJMwQN1WAQ4ohi+6NYDCFFSr4GfwgXKNwgAPMC8dlnRXj iyOATY4dMHEzaVseTkvyNdE= X-Google-Smtp-Source: AAOMgpeGE/Yp9dtPhtXBcQdvD8m9gmn321doBtDPtgNWn6LK8EHemepZPqyk7iIwHVCni4EQxAq4qQ== X-Received: by 2002:ab0:4a53:: with SMTP id r19-v6mr6292919uae.98.1530189616469; Thu, 28 Jun 2018 05:40:16 -0700 (PDT) Received: from [10.196.220.133] (41-197.icannmeeting.org. [199.91.197.41]) by smtp.gmail.com with ESMTPSA id c10-v6sm1956359vka.56.2018.06.28.05.40.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 05:40:15 -0700 (PDT) From: Fred Baker Message-Id: <591F72A8-0E55-462E-BE4F-F1EB00E93FFC@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7F04217C-E0D3-4BFC-9FEC-E5502B91CE38"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 28 Jun 2018 07:40:13 -0500 In-Reply-To: Cc: "v6ops@ietf.org list" To: JORDI PALET MARTINEZ References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <9921F0BA-F2A5-4214-A133-1C8F4AF7CB6A@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 12:40:19 -0000 --Apple-Mail=_7F04217C-E0D3-4BFC-9FEC-E5502B91CE38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 28, 2018, at 7:30 AM, JORDI PALET MARTINEZ = wrote: > Do you think it makes sense today for a smart OS or app provider, = knowing that that app need to talk to IPv4-only hosts, to make that app = or OS, IPv6-only? I'm not making a market statement. I'm looking at a technical scenario, = which I laid out in email yesterday. It could be IPv6-only because the = network didn't give it an IPv4 address, to pick one possible reason out = of a cloud of possible ones. The point is, it *is*, and if the peer it = wants to talk with doesn't have a AAAA record, whether native or DNS64, = it can't. So the failure of DNSSEC when DNS64 is used isn't the only issue. = Connectivity is also an issue. That's my whole point. --Apple-Mail=_7F04217C-E0D3-4BFC-9FEC-E5502B91CE38 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+AFAls01y0ACgkQEhdRnd2G P+CXvQ//c9+h90QQQ36JThWKA+a9meONd66w/B9PhPOVkO/AoHC+ftRV23hFLhEh XM60x6ztC+mpY/r0iqd13WNCjjPjxONn6Wc/D1arR7MrYlFuTCNKaAVowxCSCIH9 gTiJ0SK1jsw8hO9tER3mp1G4asx/FQ/6LTlHVbTaUC847sSX0cGBnP80NaNV9txS qLVPZO++dMPrp0YaNT+2Yi0sIUtgPa5f9UnHhjcENFaZWWAoxilx1/JoW2JJM+r6 d/j5FI71MpXgOB/bAruQlpYGt1TPme8qMbwvswSWJzTNL1SC+tOdkfdkU7hlm0jn Z4t0PvsbmWmqutwV4D40CNBiHhJRDEvp8c6QcVDveOCCmw/2/scEWU8IrdYTn97v yZa5PAhXxPdaHBnk2GxQw984Zm6MFy3Oybza7tPLNjiZgWdb/+OtUHwt5XDckDv+ 20A7p4Z+mPnPvqX8Z6sBW/Wkq2o4Gpy8vks+TrifDwBA9y2XtYI/rXRSTvByEzXC FeM/SJXFP8SCqOVpJhH1rz+cRPdGicPIBeBUc2SRloVHulYTXc2xxXrLI/Q6DKZo XG7HGx2My0dQ4sdFIJCD19ReVIpf3GiVDXhpo70cjpYhzbKzDmlmsGiqtbnwHE12 +Je7lfNZz7nQ0+07hGWoJqq98YJipo3P+sq9F5ltfRRnS5KVf5k= =x5ku -----END PGP SIGNATURE----- --Apple-Mail=_7F04217C-E0D3-4BFC-9FEC-E5502B91CE38-- From henri.godoy@fca.unicamp.br Thu Jun 28 09:54: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 906E7130EBE for ; Thu, 28 Jun 2018 09:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fca.unicamp.br Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_52BhhajzDq for ; Thu, 28 Jun 2018 09:54:39 -0700 (PDT) Received: from mail.fca.unicamp.br (mail.fca.unicamp.br [IPv6:2801:8a:c040:fca0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1E7130E9D for ; Thu, 28 Jun 2018 09:54:39 -0700 (PDT) Received: from webmail.fca.unicamp.br (mail.fca.unicamp.br [143.106.230.3]) by mail.fca.unicamp.br (Postfix) with ESMTP id 1D705DC0A43 for ; Thu, 28 Jun 2018 13:54:33 -0300 (-03) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.fca.unicamp.br 1D705DC0A43 Authentication-Results: mail.fca.unicamp.br; dmarc=pass (p=quarantine dis=none) header.from=fca.unicamp.br Authentication-Results: mail.fca.unicamp.br; spf=pass smtp.mailfrom=henri.godoy@fca.unicamp.br DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fca.unicamp.br; s=default; t=1530204873; bh=5X8Dzh+k26jooMGgQwkcYrS903Kz9lCI4rQ/j/5/pZY=; h=Date:From:To:Subject; b=mYRezxpfQW10JcOWvu4Gor5CecRTrcBnCIRB3VbfhvhRrQD8+xXFh8ID8u4AL9FHT mc4GZOuTOEwdowRFUZs+G1pdKiFsi4Ci6L7kSrBA/aQQBBlSc4MJJBhP72yLMqwDoQ iM5pDzxFIPOHsNZ2ECva/URTkVb4Gba532GLl45o= Received: from 2801:8a:c040:fca0:a4fa:fd43:db67:c912 by webmail.fca.unicamp.br with HTTP (HTTP/1.1 POST); Thu, 28 Jun 2018 13:54:33 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 28 Jun 2018 13:54:33 -0300 From: Henri Alves de Godoy To: v6ops@ietf.org Message-ID: <0d0b4fc57e005ebe8358db8eccf0c7f9@fca.unicamp.br> X-Sender: henri.godoy@fca.unicamp.br User-Agent: Roundcube Webmail/1.3.4 Archived-At: Subject: [v6ops] NAT64/464XLAT Deployment Guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 17:02:15 -0000 Hi v6ops list members. My name is Henri and I am a network administrator at the University of Campinas, UNICAMP / Brazil. We no longer have ipv4 to deliver to the end users of a wireless network. Our wireless traffic overtook the wired network. We are researching and doing some testing with NAT64 / DNS64 for delivery of ipv6-only to the academic community. I believe that the discussion of this draft is important and could help us to implement NAT64 in the university, as well as to better understand the scenario and the problems that will come. Thanks Att, -- Henri Alves Godoy Tecnologia da Informação e Comunicação Faculdade de Ciências Aplicadas - FCA Universidade Estadual de Campinas - UNICAMP Fone: +55 (19) 3701-6682 From nobody Thu Jun 28 12:47: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 DA4F4131068 for ; Thu, 28 Jun 2018 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfQSV-ZOPChf for ; Thu, 28 Jun 2018 12:47:09 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5A8131058 for ; Thu, 28 Jun 2018 12:47:09 -0700 (PDT) Received: from [192.168.1.116] (host-79-121-42-98.kabelnet.hu [79.121.42.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5SJl0fg074911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 28 Jun 2018 21:47:06 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-98.kabelnet.hu [79.121.42.98] claimed to be [192.168.1.116] To: v6ops@ietf.org References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu> Date: Thu, 28 Jun 2018 21:46:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.98; helo=[192.168.1.116]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 19:47:12 -0000 Dear Fred and Jordi, As an academic researcher, I think this draft makes sense and I support its adoption. I have one minor comment regarding the figure below: >> 3.1.2. Service Provider offering 464XLAT, with DNS64 > Pictorial image of what I'm picturing: > > +----+ +----+ > |DNS | +-----+ |DNS | > |IPv6| |DNS64| |IPv4| > +--+-+ +--+--+ +--+-+ > +------+ v6 +------+ | | | > | +----+ | ,--+--. | ,--+--. > |Dual | | IPv6 | / \ ,-+-. / \ > |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) > |Device|v4|C| | \Network/`. `---' \Network/ > | +--+L| | `--+--' `. /`-----' > +------+ |A| | | `+------+ > |T| | +--+---+ | Peer | > +-+------+ | IPv6 | |Device| > |Device| +------+ > +------+ Connecting the DNS64 server to the PLAT device suggests me as if DNS64 were a kind of subfunction of PLAT. Of course it is not the case. They can be implemented by two independent devices: stateful NAT64 is usually implemented by a router and DNS64 is usually implemented by a DNS server. I have been thinking about an alternative drawing like this: +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +-----+ +--+-+ +------+ v6 +------+ | / \ | | +----+ | ,--+--. / \ ,--+--. |Dual | | IPv6 | / \/ ,---. \/ \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ What do you think of it? Best regards, Gabor From nobody Thu Jun 28 13:59: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 6A2B0130F39 for ; Thu, 28 Jun 2018 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApLoj9jvEdBL for ; Thu, 28 Jun 2018 13:58:58 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAC41310D7 for ; Thu, 28 Jun 2018 13:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530219535; x=1530824335; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=BMFxgEod 11k+SVpeGndHipK5j0VlBJeF0gNBG/axy0Q=; b=Gly437EtJ/rbkulJyKC3xseC +RHreeZcnkTKiz1+ZopUICq4nxh2Yz94abuO/vkQJhXBEYDgjiivkuQ/zZLEh+A/ HO3gB7URby8rfnBgjgatk98XrhsNEL3CLox8CutF6kOG94Y6JhSYmE5MLLmou3SU h3YVm218jzuZADplsd8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 28 Jun 2018 22:58:55 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Jun 2018 22:58:55 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005800045.msg for ; Thu, 28 Jun 2018 22:58:54 +0200 X-MDRemoteIP: 2001:470:1f09:495:b929:51b1:8b6b:229c X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 28 Jun 2018 22:58:54 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17172b6c16=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 28 Jun 2018 22:58:51 +0200 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: <427C7EE4-7B07-4094-9315-01E03A5120B3@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu> In-Reply-To: <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:59:16 -0000 Thanks Gabor! I think the location of the DNS64 is not relevant, unless I'm missing somet= hing ... In fact, the "easier and most common" scenario is that the DNS its= elf (Bind, etc.), is also running the DNS64 function. We could have 10 different pictures for it, the point is to clarify impacts= of having it vs not, so to provide a decision point to an operator/enterpr= ise willing to deploy it. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Lencse G=C3=A1bor Fecha: jueves, 28 de junio de 2018, 21:48 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments Dear Fred and Jordi, =20 As an academic researcher, I think this draft makes sense and I support= =20 its adoption. =20 I have one minor comment regarding the figure below: =20 >> 3.1.2. Service Provider offering 464XLAT, with DNS64 > Pictorial image of what I'm picturing: > > +----+ +----+ > |DNS | +-----+ |DNS | > |IPv6| |DNS64| |IPv4| > +--+-+ +--+--+ +--+-+ > +------+ v6 +------+ | | | > | +----+ | ,--+--. | ,--+--. > |Dual | | IPv6 | / \ ,-+-. / \ > |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) > |Device|v4|C| | \Network/`. `---' \Network/ > | +--+L| | `--+--' `. /`-----' > +------+ |A| | | `+------+ > |T| | +--+---+ | Peer | > +-+------+ | IPv6 | |Device| > |Device| +------+ > +------+ =20 Connecting the DNS64 server to the PLAT device suggests me as if DNS64= =20 were a kind of subfunction of PLAT. Of course it is not the case. They= =20 can be implemented by two independent devices: stateful NAT64 is usuall= y=20 implemented by a router and DNS64 is usually implemented by a DNS serve= r. =20 I have been thinking about an alternative drawing like this: =20 +----+ +----+ |DNS | +-----+ |DNS | |IPv6| |DNS64| |IPv4| +--+-+ +-----+ +--+-+ +------+ v6 +------+ | / \ | | +----+ | ,--+--. / \ ,--+--. |Dual | | IPv6 | / \/ ,---. \/ \ |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) |Device|v4|C| | \Network/`. `---' \Network/ | +--+L| | `--+--' `. /`-----' +------+ |A| | | `+------+ |T| | +--+---+ | Peer | +-+------+ | IPv6 | |Device| |Device| +------+ +------+ =20 =20 What do you think of it? =20 Best regards, =20 Gabor =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Jun 29 01:15: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 23653130DBE for ; Fri, 29 Jun 2018 01:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1H9tBmt30uVU for ; Fri, 29 Jun 2018 01:15:54 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDCA12F295 for ; Fri, 29 Jun 2018 01:15:53 -0700 (PDT) Received: from [192.168.1.116] (host-79-121-42-98.kabelnet.hu [79.121.42.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w5T8FdVm086682 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 29 Jun 2018 10:15:47 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-98.kabelnet.hu [79.121.42.98] claimed to be [192.168.1.116] To: v6ops@ietf.org References: <663F489C-7F63-4B0C-A5E6-F7EE4634E62B@gmail.com> <6ac32868-e0eb-00b7-2c3e-29c33c168323@hit.bme.hu> <427C7EE4-7B07-4094-9315-01E03A5120B3@consulintel.es> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Fri, 29 Jun 2018 10:15:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <427C7EE4-7B07-4094-9315-01E03A5120B3@consulintel.es> Content-Type: multipart/alternative; boundary="------------A6BF76E28BC9D01E08D977F2" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.98; helo=[192.168.1.116]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 08:15:58 -0000 This is a multi-part message in MIME format. --------------A6BF76E28BC9D01E08D977F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 6/28/2018 10:58 PM keltezéssel, JORDI PALET MARTINEZ írta: > Thanks Gabor! > > > > I think the location of the DNS64 is not relevant, unless I'm missing something ... Yes, I agree. The location of DNS64 by itself is not my concern. What I would like to emphasize is that DNS64 does not belong to NAT64. The reason, why I am aware of this is my experience with DNS64 and NAT64 benchmarking. In all other research papers than ours, they measured the performance of a given NAT64 implementation together with a given DNS64 implementation, which is a significant flaw. We have pointed out that their performances should be measured independently. And our approach was followed by RFC 8219, too. > In fact, the "easier and most common" scenario is that the DNS itself (Bind, etc.), is also running the DNS64 function. You mentioned BIND, which is natural, as BIND is still considered the de facto industry standard DNS server. However, when talking about DNS64, BIND is the worst solution. According to our benchmarking results, ISP-s should choose either Unbound or PowerDNS as DNS64 server, but not BIND. Let me support my statement with measurement results: PowerDNS Unbound BIND 1-core DNS64 performance (queries per second) 3077 8708 2425 16-core DNS64 performance (queries per second) 26620 17131 6661 The measurements complied with RFC 8219. For the details, please refer to: G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", /Computer Communications/ (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 I think it would be worth mentioning these results in the draft, as they give useful guidelines for the DNS64 server implementation selection. Best regards, Gábor > > > We could have 10 different pictures for it, the point is to clarify impacts of having it vs not, so to provide a decision point to an operator/enterprise willing to deploy it. > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: v6ops en nombre de Lencse Gábor > > Fecha: jueves, 28 de junio de 2018, 21:48 > > Para: > > Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments > > > > Dear Fred and Jordi, > > > > As an academic researcher, I think this draft makes sense and I support > > its adoption. > > > > I have one minor comment regarding the figure below: > > > > >> 3.1.2. Service Provider offering 464XLAT, with DNS64 > > > Pictorial image of what I'm picturing: > > > > > > +----+ +----+ > > > |DNS | +-----+ |DNS | > > > |IPv6| |DNS64| |IPv4| > > > +--+-+ +--+--+ +--+-+ > > > +------+ v6 +------+ | | | > > > | +----+ | ,--+--. | ,--+--. > > > |Dual | | IPv6 | / \ ,-+-. / \ > > > |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) > > > |Device|v4|C| | \Network/`. `---' \Network/ > > > | +--+L| | `--+--' `. /`-----' > > > +------+ |A| | | `+------+ > > > |T| | +--+---+ | Peer | > > > +-+------+ | IPv6 | |Device| > > > |Device| +------+ > > > +------+ > > > > Connecting the DNS64 server to the PLAT device suggests me as if DNS64 > > were a kind of subfunction of PLAT. Of course it is not the case. They > > can be implemented by two independent devices: stateful NAT64 is usually > > implemented by a router and DNS64 is usually implemented by a DNS server. > > > > I have been thinking about an alternative drawing like this: > > > > +----+ +----+ > > |DNS | +-----+ |DNS | > > |IPv6| |DNS64| |IPv4| > > +--+-+ +-----+ +--+-+ > > +------+ v6 +------+ | / \ | > > | +----+ | ,--+--. / \ ,--+--. > > |Dual | | IPv6 | / \/ ,---. \/ \ > > |Stack | +-+Router+--( IPv6 )--( PLAT)--( IPv4 ) > > |Device|v4|C| | \Network/`. `---' \Network/ > > | +--+L| | `--+--' `. /`-----' > > +------+ |A| | | `+------+ > > |T| | +--+---+ | Peer | > > +-+------+ | IPv6 | |Device| > > |Device| +------+ > > +------+ > > > > > > What do you think of it? > > > > Best regards, > > > > Gabor > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > --------------A6BF76E28BC9D01E08D977F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    6/28/2018 10:58 PM keltezéssel, JORDI PALET MARTINEZ írta:
    Thanks Gabor!



I think the location of the DNS64 is not relevant, unless I'm missing something ...

    Yes, I agree. The location of DNS64 by itself is not my concern. What I would like to emphasize is that DNS64 does not belong to NAT64. The reason, why I am aware of this is my experience with DNS64 and NAT64 benchmarking.

    In all other research papers than ours, they measured the performance of a given NAT64 implementation together with a given DNS64 implementation, which is a significant flaw. We have pointed out that their performances should be measured independently. And our approach was followed by RFC 8219, too.
     
    In fact, the "easier and most common" scenario is that the DNS itself (Bind, etc.), is also running the DNS64 function.

    You mentioned BIND, which is natural, as BIND is still considered the de facto industry standard DNS server.

    However, when talking about DNS64, BIND is the worst solution. According to our benchmarking results, ISP-s should choose either Unbound or PowerDNS as DNS64 server, but not BIND. Let me support my statement with measurement results:


    		 PowerDNS Unbound BIND
    1-core DNS64 performance (queries per second) 3077 8708 2425
    16-core DNS64 performance (queries per second) 26620 17131 6661
             
    The measurements complied with RFC 8219. For the details, please refer to:

    G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005

    I think it would be worth mentioning these results in the draft, as they give useful guidelines for the DNS64 server implementation selection.

    Best regards,

    Gábor

    

We could have 10 different pictures for it, the point is to clarify impacts of having it vs not, so to provide a decision point to an operator/enterprise willing to deploy it.



Regards,

Jordi

 

 



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

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse Gábor <lencse@hit.bme.hu>

Fecha: jueves, 28 de junio de 2018, 21:48

Para: <v6ops@ietf.org>

Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments



    Dear Fred and Jordi,

    

    As an academic researcher, I think this draft makes sense and I support 

    its adoption.

    

    I have one minor comment regarding the figure below:

    

    >> 3.1.2.  Service Provider offering 464XLAT, with DNS64

    > Pictorial image of what I'm picturing:

    >

    >                            +----+                +----+

    >                            |DNS |     +-----+    |DNS |

    >                            |IPv6|     |DNS64|    |IPv4|

    >                            +--+-+     +--+--+    +--+-+

    >    +------+ v6 +------+       |          |          |

    >    |      +----+      |    ,--+--.       |       ,--+--.

    >    |Dual  |    | IPv6 |   /       \    ,-+-.    /       \

    >    |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )

    >    |Device|v4|C|      |   \Network/`.  `---'    \Network/

    >    |      +--+L|      |    `--+--'   `.         /`-----'

    >    +------+  |A|      |       |        `+------+

    >              |T|      |    +--+---+     | Peer |

    >              +-+------+    | IPv6 |     |Device|

    >                            |Device|     +------+

    >                            +------+

    

    Connecting the DNS64 server to the PLAT device suggests me as if DNS64 

    were a kind of subfunction of PLAT. Of course it is not the case. They 

    can be implemented by two independent devices: stateful NAT64 is usually 

    implemented by a router and DNS64 is usually implemented by a DNS server.

    

    I have been thinking about an alternative drawing like this:

    

                               +----+                +----+

                               |DNS |     +-----+    |DNS |

                               |IPv6|     |DNS64|    |IPv4|

                               +--+-+     +-----+    +--+-+

       +------+ v6 +------+       |      /       \      |

       |      +----+      |    ,--+--.  /         \  ,--+--.

       |Dual  |    | IPv6 |   /       \/   ,---.   \/       \

       |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )

       |Device|v4|C|      |   \Network/`.  `---'    \Network/

       |      +--+L|      |    `--+--'   `.         /`-----'

       +------+  |A|      |       |        `+------+

                 |T|      |    +--+---+     | Peer |

                 +-+------+    | IPv6 |     |Device|

                               |Device|     +------+

                               +------+

    

    

    What do you think of it?

    

    Best regards,

    

    Gabor

    

    

    _______________________________________________

    v6ops mailing list

    v6ops@ietf.org

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

    




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

    --------------A6BF76E28BC9D01E08D977F2-- From nobody Fri Jun 29 09:22: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 60B0A130E22 for ; Fri, 29 Jun 2018 09:22:30 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 2DYLzZqi0-Bf for ; Fri, 29 Jun 2018 09:22:28 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15307130E1C for ; Fri, 29 Jun 2018 09:22:28 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 188-v6so3623591ita.5 for ; Fri, 29 Jun 2018 09:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=y2wlpd17o+oFQTKZ0oG2SU0de2jjC5wZ8RSxRW97ylk=; b=TvNch9Z1uHMSL3+8D7T61XQ0n2LUgHXVOqWTg1BiyUwi0tcz07ZzwbNwNSPa8oS2kS DJfuoJGfvNNKroKiYSLoolKJW2Tl5RR41hgs2gOZ9GOpIZ7sAcieJRJc/UMtY6MJMukf AABbAK+T0ExBx+92gxL9zEeCa15UNhy7aWL06rxlOUFWaAhHaKwGBDU/ogPlC09dysHU t5MzLUc3rDPJaGjn9/kvN+CMjwXSsyQ/6zDzCRmKGsIdj4FRWdavaITk0stcvF9iI6hV cKrQVbFT/OLlghtMpMkMJP8apPhGvznvkkGHgqUbjU9K3rTNtAxG0InvtWl51bQbwnI6 a52w== 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:content-transfer-encoding; bh=y2wlpd17o+oFQTKZ0oG2SU0de2jjC5wZ8RSxRW97ylk=; b=MBweyfez+EjiSeoGeC6PwTOKtAQvxefLZC8ngGylyWBGEDcOXjpcvzHcNNEqi1U6Yn sZEBEKkvt6vlY2ShohZ5KO7eT7qtz3LQFppox3E2KQlPK8x65Lhpwi6fWUfsc6yhUEcH rg+6NqYGPA3Nh43YBxMX2u6EJs3LDBQ8nPbCeaD9+hWjvmh+kyS0GwsVjhq9YIGbCxVT btItLsNt7aNWaaUp7Qc2T221WNrYoEiONTf4EqS1fUpWBDz9YIU98ouoLFDoPoVOmdCG lTWv080VrMpe1UsgOT1ogToHbE3VIwz+BzV52b1599gsb7ykhf4sWMqbPxhXs1zyRZrP 5MRw== X-Gm-Message-State: APt69E3hMQDTG9bLvcGAv5FB8Gun/xJeg1sX97loGSnn3RNaMaKEgZd2 mGxytuV7EXla+x2STXNKw12qmPSToHU= X-Google-Smtp-Source: AAOMgpfiGJK35SQFWeSD7VcW2wrLq9Ey8cWXT0L4tmoxFwVjPduKfwVzYboNQVlWu5CS2LKklPLJQQ== X-Received: by 2002:a24:f007:: with SMTP id s7-v6mr2472715ith.15.1530289347342; Fri, 29 Jun 2018 09:22:27 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id y64-v6sm971179itb.33.2018.06.29.09.22.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 09:22:26 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id a195-v6so3613328itd.3; Fri, 29 Jun 2018 09:22:26 -0700 (PDT) X-Received: by 2002:a24:9f81:: with SMTP id c123-v6mr2306569ite.81.1530289346607; Fri, 29 Jun 2018 09:22:26 -0700 (PDT) MIME-Version: 1.0 References: <153028888719.30408.10959407547473028450.idtracker@ietfa.amsl.com> In-Reply-To: From: Richard Patterson Date: Fri, 29 Jun 2018 17:22:15 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" , intarea-chairs@ietf.org, dhcwg@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:22:31 -0000 Version -03 of =EF=BB=BFdraft-patterson-intarea-ipoe-health has now been up= loaded. Thanks to Med, Jean-Yves and Dusan for their review and comments. The noteworthy changes since -02 include: - Added DHCP option flag to force ARP/ND for health checks. - Populated IANA Considerations. - Added Retry Interval distinct timer for between failed checks. - Added default parameter values. -Richard On 29/06/2018, 17:14, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-patterson-intarea-ipoe-health-03.txt has been successfully submitted by Richard Patterson and posted to the IETF repository. Name: draft-patterson-intarea-ipoe-health Revision: 03 Title: IP over Ethernet (IPoE) Session Health Checking Document date: 2018-06-29 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-03= .txt Status: https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ Htmlized: https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-patterson-intarea-ipoe-health-03 Abstract: PPP over Ethernet clients have the functionality to detect path unavailability by using PPP Keepalives. IP over Ethernet does not have this functionality, and it is not specified in the IETF when an IP over Ethernet client should consider its WAN connectivity down, unless there is a physical layer link down event. This document describes a mechanism for IP over Ethernet clients to achieve connectivity validation, similar to that of PPP over Ethernet, by using BFD Echo, or ARP and Neighbor Discovery functions= . Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jun 29 18:14: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 A8354130F99 for ; Fri, 29 Jun 2018 18:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NCnfChJpAjRg for ; Fri, 29 Jun 2018 18:14:17 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2834130F93 for ; Fri, 29 Jun 2018 18:14:17 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id q11-v6so9599935otk.4 for ; Fri, 29 Jun 2018 18:14:17 -0700 (PDT) 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=mRMQQ28sskZkT8zzYZ/9/aGjERBWdwazJs0+RBQd1/Q=; b=uDD4my/JjAvD5sesbXQH+7a1B0NrgZzeWAWbR24YkelKSF+y1du6S3qBrSwQBeSEBB Kb7io6qXltfF4igbPN18oIrM/jKauvBDK8XZtW008wkohNa5DQFNTUSf+DBF8TqkUgZ/ Stuzz8TES9FBtsk1wxxa+LzpzwkeapAGINp8G4DFT0qp0ljs3td1Z8Ol0Ho3Hqw0vOuB ENl4qx/9bBHGhdePxg1ukj8guDWcDxnZGnr1hb74iUxqo88jo98m1GYhDWwJhFbpwcya Whzrd72tC2NiURWKvE4fVLw+Pf+9wIi6U5FEKxJtBhHrDLPDHr1n2VrQ0KuI1n1Gql2L Obgg== 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=mRMQQ28sskZkT8zzYZ/9/aGjERBWdwazJs0+RBQd1/Q=; b=MCPuz7OCZIFJOEMQjJi1czvHFvkDwaB4sNLPVAqjrBsp/Z2ooDvtaM3ETScD5ChK9I +bSkdqHqJ158CjSqe8Z7EAkluTZ/y7qzlfn77S1H1uZEfk5HvjxqZYZR3vMT5ODjUXfo mkV/lW04PNxkI7QpWEgj7V2M5ONI1fg5sutOHulyBS0ZQ3RET4618qZZbHmYU5VCVIiO uRvVp63aMr9Ipg90uZsWA6p4cmsCgjVWoiIMasBGJBzgpKxLsL0o75dmgZX1zI052Osg cOkNJxEyfDZyurvuH5k4H1ouHh6RPsGn7a4nCiLqwUz4cZ3gH+kw0llbn0fJ0Wd8w/bI PskA== X-Gm-Message-State: APt69E0azT8r4emmjxJyjCrCqN8KZh+XfpQBcNBBjt5OGq8WuV1oF4Yp DlvrWuJ+Bk1BaugMIzFthMGOk8RZ X-Google-Smtp-Source: AAOMgpeTLk/vOXyT3TqjwPi7YZP/scv1VoxJEX0OLavKExdCXo027duh3bJFUfTpoxhTeR4U7FEezw== X-Received: by 2002:a9d:3c8a:: with SMTP id z10-v6mr2115281otc.363.1530321256916; Fri, 29 Jun 2018 18:14:16 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::101b? ([2600:8802:5600:1546::101b]) by smtp.gmail.com with ESMTPSA id l91-v6sm5170363otc.81.2018.06.29.18.14.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 18:14:16 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_C48753D1-465A-4A31-97F0-43FA2494D6CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <2C319A87-179E-430C-9364-E0FF30EAA408@gmail.com> Date: Fri, 29 Jun 2018 18:14:14 -0700 To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [v6ops] Three new drafts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 01:14:20 -0000 --Apple-Mail=_C48753D1-465A-4A31-97F0-43FA2494D6CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft cutoff for IETF 102 is Monday = (https://datatracker.ietf.org/meeting/important-dates/). If you have = something to add, now would be the time to do it. I note that we have had three drafts posted in the past week. We have = had some supportive discussion of draft-palet-v6ops-nat64-deployment, = and I am adding it the the agenda for IETF 102. We also have (and I am = soliciting feedback on) draft-palet-v6ops-rfc6177-bis, which is a = partial rewrite of RFC 6177, and draft-jaeggli-v6ops-indefensible-nd, = which is a new draft. Per our procedures, I need the working group to = tell us whether they want these on the agenda. https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment https://tools.ietf.org/html/draft-jaeggli-v6ops-indefensible-nd Note that there may be other new drafts by Monday at UTC 23:59. I'll = mention them Tuesday if I see them. --Apple-Mail=_C48753D1-465A-4A31-97F0-43FA2494D6CF 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+AFAls22WYACgkQEhdRnd2G P+CPwg/7B4lKTTFk4bOplhsPVtRJC/wBqWdVHtYcnWnRPsG1Y9tKe2Zjdj/utwzV 8YFXl4FjV1IXFSHJBX8jZ+LYL6cXUMf44HI+xffRwnnBzoaKaXZ50wr4wtoeBiHG sexvq1TDCwx9E2d/j6NvjAqDYJfAGuUiikCm73iHZbAW9RB+E/4hQm7e50Qd6N59 95Wa4vuQ1q8PHklA74U+sn36dDnuJZM26YTINr5/mSLO7wWYwinwJQCPia55mSnC q6VlqjCD7wi0S5TXmgWkpSfcZajjyX97NieSa9q1/UE9zl/hNRSdY18mqtzpAJhp WA3abh1QwwrTPBX+2UrzO/CYGdQazK3i4LgQt4eBJ5aHXEVhIWhpuLX5T1WaEGZT 06xc/skMg/2tN8TPNP1IyYZXqv+K+5cM/d7WqxT4fu9XcS4zxblb7JwLtUklb7Mk yM14cy2ogJS3ntxTCGIjQ6cJzwsDUxZ0iiSyP6CbPvhZeQFOJomjPOogGL9y7hh2 J7lIhEmbp3B3qEtMBuV5Fknt9F9LFQdHYEeFu9XsJXw9SRpv5Hd/7WER8wlWhxx4 f66FZiMU7yQYkDDzc1qnxG+6IBYfrGggi/EQ4UnZxwFYK7cC9sKm+vBXBmPOi+ii Pf6/N0wt1ebW8TFtsZEQ4y8cVW5ulAoYr+oFNEBHUQp9dFN7LCU= =7luc -----END PGP SIGNATURE----- --Apple-Mail=_C48753D1-465A-4A31-97F0-43FA2494D6CF-- From nobody Sat Jun 30 00:16: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 55793131023 for ; Sat, 30 Jun 2018 00:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKXrjTJ2m5IS for ; Sat, 30 Jun 2018 00:16:11 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 8C07D1277BB for ; Sat, 30 Jun 2018 00:16:11 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id l15-v6so12275338oth.6 for ; Sat, 30 Jun 2018 00:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=RHuQcC8zXOwBYdpXuKoIRdNRfw+p5rs0EOjx60InMhw=; b=itXJsOte5aa46A/gIQQ6ZtH6O17Im28b5ExwD5FFXGkJd+bzkW5z725gzPZhw/J/Q7 go6GQU1dZIS+Er2Ibe5rnQgmPx7uxqpAjAwFyXOJVUaSrMVjm6wm56kYDMNvcs9N0JEP JtgHWYHFFpeFOsUvnPP0tfvNRmlnhUP5njtqZKI25gR3BeUMrC49ni/y4mTw8/nGv525 Xcwfey/y7BbMPC+25XZIVOsXPsUCIX9a8NbvJe6qbNxpUnUqdD07gZNxGfCo1mfa9Usj KRqlaw+Bat16yEE5ic2kCe8Fl1xsTHAlhHDjbZNc0dVUq/dXl5auPuk2tZQvZL6ICFic 7y/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=RHuQcC8zXOwBYdpXuKoIRdNRfw+p5rs0EOjx60InMhw=; b=aPQUeuvWT9AAPeoPUzELe2K7fT4Df3dK8y19VSkdR5rMikvqRLixBHhngai77v4ONd 0o7HdCn+LrorXjdvSBj/dcx81sAo1Ximh67oRtCmwNTaXHaEFwb+Fvsoce8T3uZ6RVFn iBx6J/okd/tGHMDxAbs4TqHYcgcfS+RmoGZ4W4Zl2uB4xhSDmMCbuAsu+mbSfl91sQWC TztxPWrxgs/ar8SGRLigZfpsA8YlSA5lTfkuGMd3mmOunZFT5NyYkkPzW9I6p0r0wCdQ qP6epuX5UFly+F5m2jdMnXQvy0Qg44y2H9J6Cr0AuLmvu1EOjw9ZVDMoZHB7tzfRV72v 1SGA== X-Gm-Message-State: APt69E0jnQz1exdBlcAXEms5id1MHyulArdLt+gQ7kMLI6IeqmCDvIvR tc6f9T6a/icVjJNIuJZ4yR5LUOPA X-Google-Smtp-Source: AAOMgpd2aDGGkdxc2pxumZkc+0EA+/zeBCor9W4fHzhTXuajflzGvbveeuyRMyjYFWoGk77Xm8KWRA== X-Received: by 2002:a9d:b3:: with SMTP id w48-v6mr675298oti.224.1530342970704; Sat, 30 Jun 2018 00:16:10 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::101c? ([2600:8802:5600:1546::101c]) by smtp.gmail.com with ESMTPSA id m3-v6sm5288784oif.26.2018.06.30.00.16.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jun 2018 00:16:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Fred Baker Mime-Version: 1.0 (1.0) Date: Sat, 30 Jun 2018 00:16:06 -0700 Message-Id: <057742AA-226E-44F8-819E-C865D7F58758@gmail.com> To: v6ops@ietf.org X-Mailer: iPad Mail (16A5308e) Archived-At: Subject: [v6ops] Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 07:16:15 -0000 > Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 ht= tps://news360.com/article/460267064 IPv6 Jon the press. Thinking about this as we approach IETF 102, where IPv4 o= verlaid on or translated to IPv6 is on the agenda. Sent from my iPad= From nobody Sat Jun 30 00:47: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 67F9313103A for ; Sat, 30 Jun 2018 00:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w3THaM-jQVS for ; Sat, 30 Jun 2018 00:47:52 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5025131036 for ; Sat, 30 Jun 2018 00:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1530344869; x=1530949669; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=ubXBFqQQ cI4Djf3XR4fKg+i9M3XzWRQpWf4FQjkED2w=; b=ZO2EYF3LVLWDJFKbcZYQzOJy pBFV2ncnNOYUyAfcmYr4sX3jE2lYOaepBoiizkTeG5KRUuWb4Ya7a00bHO2tz9j5 pcuiCbcvhzITdtj8hBOVjIUbmeB3Tdy7TNkJaO7f2Tznfap5+D9QunEWfFfoXQLI sL9+ChfP9I8+mjc/2Es= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 30 Jun 2018 09:47:49 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 30 Jun 2018 09:47:49 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005800841.msg for ; Sat, 30 Jun 2018 09:47:49 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8e3:e1ce:6974:d7df X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sat, 30 Jun 2018 09:47:49 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1719f229c3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Sat, 30 Jun 2018 09:47:48 +0200 From: JORDI PALET MARTINEZ To: Fred Baker , Message-ID: <1CB1AE09-17BB-4205-9793-05988877BA65@consulintel.es> Thread-Topic: [v6ops] Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 References: <057742AA-226E-44F8-819E-C865D7F58758@gmail.com> In-Reply-To: <057742AA-226E-44F8-819E-C865D7F58758@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 07:47:55 -0000 Interesting, they took it from the APNIG and RIPE blogs which this week pub= lished an article on that ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: s=C3=A1bado, 30 de junio de 2018, 9:17 Para: Asunto: [v6ops] Time to dump dual-stack networks and get on the IPv6 train = - with LW4o6 > Time to dump dual-stack networks and get on the IPv6 train - with LW4= o6 https://news360.com/article/460267064 =20 =20 IPv6 Jon the press. Thinking about this as we approach IETF 102, where = IPv4 overlaid on or translated to IPv6 is on the agenda. =20 Sent from my iPad _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From ccebrian@walhallacloud.com Sat Jun 30 02:38: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 D163B131045 for ; Sat, 30 Jun 2018 02:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx4Lts7BGowe for ; Sat, 30 Jun 2018 02:38:13 -0700 (PDT) Received: from newatlas.tissat.es (newatlas.tissat.es [91.232.71.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8AA130EE4 for ; Sat, 30 Jun 2018 02:38:11 -0700 (PDT) Received: from NEWATLAS.tissat.local ([10.128.55.100]) by NEWATLAS.tissat.local ([10.128.55.100]) with mapi id 14.03.0266.001; Sat, 30 Jun 2018 11:38:04 +0200 From: Carlos Cebrian To: "v6ops@ietf.org" Thread-Topic: draft-palet-v6ops-nat64-deployment Thread-Index: AdQQVg4nBUP+1RyJRlSVKBUzQQUf1w== Date: Sat, 30 Jun 2018 09:38:04 +0000 Message-ID: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [85.52.50.156] Content-Type: multipart/related; boundary="_004_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_"; type="multipart/alternative" MIME-Version: 1.0 X-Antivirus: Avast (VPS 180629-6, 29/06/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [v6ops] draft-palet-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 09:51:16 -0000 --_004_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_ Content-Type: multipart/alternative; boundary="_000_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_" --_000_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ASaan Cloud Service Provider we really believe NAT64/464XLAT guidelines are= important and may be relevant for our networks. [cid:image010.jpg@01D1B2A0.35E9EED0] Carlos Cebri=E1n R&D Dept. Director * Office: +34 96 393 99 00 ccebrian@walhallacloud.com; www.walhalla= cloud.com Walhalla Datacenter: when Data is Critical Legal warning: the information contained in this e-mail message is confiden= tial and is for the exclusive attention of the planned recipient. If you ha= ve received the message by error, please notify the sender and delete the m= essage without copying, recording or distributing it. ________________________________ Nota Legal: Este correo electronico puede contener informacion estrictament= e confidencial y es de uso exclusivo del destinatario, quedando prohibida a= cualquier otra persona su revelacion, copia, distribucion, o el ejercicio = de cualquier accion relativa a su contenido. Si ha recibido este correo ele= ctronico por error, por favor, conteste al remitente, y posteriormente proc= eda a borrarlo de su sistema. Gracias por su colaboracion. Confidentiality notice: This e-mail message may contain confidential and/or= legally privileged information and is solely for the attention and use of = the intended recipient. Any disclosure, copying, distribution or the taking= of any action with relation to the contents of this e-mail by any other pe= rson is strictly prohibited. If you believe that this e-mail has been mista= kenly sent to you, please reply to the sender from whom you received the me= ssage in error and then delete the original e-mail from your system. Thank = you for your co-operation. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --_000_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    ASaan Cloud Service Provider= we really believe NAT64/464XLAT guidelines are important and may be releva= nt for our networks.

     

     

    3D"cid:image010.jpg@01D1B2A0.35=

    Carlos Cebri=E1n=

    R&D= Dept. Director=

    ( Office:  +34 96 393 99 00

     

    ccebrian@walhallacloud.com;   = www.walhallacloud.com

    Walhalla Datacenter: when Data is Critical=

     

    Legal warning: the information contained in this e-mail mess= age is confidential and is for the exclusive attention of the planned recip= ient. If you have received the message by error, please notify the sender and delet= e the message without copying, recording or distributing it.

     


    Nota Legal: Este correo electronico puede contener informacion estri= ctamente confidencial y es de uso exclusivo del destinatario, quedando proh= ibida a cualquier otra persona su revelacion, copia, distribucion, o el eje= rcicio de cualquier accion relativa a su contenido. Si ha recibido este correo electronico por error, por favo= r, conteste al remitente, y posteriormente proceda a borrarlo de su sistema= =2E Gracias por su colaboracion.

    Confidentiality notice: This e-mail message may contain confidential= and/or legally privileged information and is solely for the attention and = use of the intended recipient. Any disclosure, copying, distribution or the= taking of any action with relation to the contents of this e-mail by any other person is strictly prohibited.= If you believe that this e-mail has been mistakenly sent to you, please re= ply to the sender from whom you received the message in error and then dele= te the original e-mail from your system. Thank you for your co-operation.


    3D"Avast

    This email has been checked for viruses by Avast antivirus software.
    www.avast.= com


    =
    --_000_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_-- --_004_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3812; creation-date="Sat, 30 Jun 2018 09:38:03 GMT"; modification-date="Sat, 30 Jun 2018 09:38:03 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAB4AMYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAMrXtZbRreKVYBL5j7cFsY4rC/wCE7l/6B6f9/D/hVrxz/wAeFt/11P8AKuLr 1cNQpzpqUlqeJjMVWp1nGMrI2b/4oT2dwYhpUb4AOTMR/Sqv/C27j/oDx/8Af8/4Vx2t/wDH+f8A dX+tZ1KFCm73XV/mVicTVhKKi/sxf3xTZ734c1dtd0SDUXhEJl3fIGzjBI6/hWpXNfD7/kTLL/gf /oZrpa86okptI9SjJypxb7BRRRUGoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ By/jn/jwtv8Arqf5Vxdd94usXu9I8yMFmt23kDuOhrga9rBNOlY+dzGLVe/c53W/+P8AP+6v9azq 0db/AOP8/wC6v9az1VncIilmY4AA5JpU9n6v8ysX8cf8MP8A0lHtPw+/5Eyy/wCB/wDoZrpayfDG mPpHhyyspf8AWxx5cejE5I/WtavJqO820e3RTjTin2QUUUVBqFFFFABRRRQAUUUUAFFFFABRRRQA UVWvtRs9MgE99cx28RbbvkOBn0osdQs9St/tFlcx3EW4rvjORkdqdna4uZXtfUs0VSstZ03UZ5IL O9hnli++iNkrzj+dRXniHR7C6Nrd6jbwzjGY3fB56cU+V3tYXPG17mlRUc00dvC80zqkcalmZjgA Dqar6fqun6qjvYXcVysZwxjbODSs7XHdXsXKKq3+pWWmQCe+uY7eMttDSHAJ9P0p1lfWuo24uLOd J4SSA6HIJHWiztcOZXtfUnIyMGuK8ReGHtne8sELQnl4h1T3HtXYXd3b2Fs9zdzJDCn3nc4A5xUV hqlhqsbyWF3Fcoh2sY2yAa1o1Z0nzR2OevRp1lyS3PDtYRpNS2RqXdgoVVGST6V3/gfwI2nOmq6s g+1DmGA8+V7n/a/lW5at4U/4SF5LaSzOqOShAbLAjOcDseucVvsyohZiAqjJJ7CtJ15WcUrXv+LJ WHpymp3vZRX3JIdRVHT9Z03VWdbC9huTHguI2ztzU17fWunWxubydIIVIBdzgDNc1nex08yte+hY oqrYalZapCZrG5juI1baWjbIB9KmuLiG1gee4kWOKMbndjgKPWizvYd1a5JRVLT9Y03Vd/2C9huf Lxv8ts7c9Ku0NNbgmmroKKr3t/aabbm4vbiO3iBALyHAyaWzvLbULZbm0nSeF87XQ5BxxRZ2uF1e xPRRRSGFFFFABRRRQBieMNP/ALT8LX0AXLrH5ifVef6VwXgjXxpfhrXELYaGMTRD/aYbf57a9XYB lKsMgjBFeAazaSaTrF9YAlVjlZMD+Jc5H9DXZh0pxcH6nmYxunONVeaNTwHqR0/xbas7fJckwuSf 73T9cVbt1/4ST4nFiN8Ruix/3I+n/oI/OqWveHpND0vR75dyvcxbpDn7r53D6cEflXQfCnTzJe32 pOM+WgiUn1PJ/kPzrom4qLqLtY5KUZOUaMu9zd+Jeq/YfDn2RGxJevs/4AOW/oPxrkvhvqTab4k+ xTZRL2Pbg8fMOVP4jP51D8RNWXUPFLwhi0NkBEAD1PVv14/Cs3V9eivtbg1OwtTZtAsYCb93KdDn A7AD8KmnT/dcttyq1b9/zp7P/hz0H4p/8ixD/wBfS/8AoLVa+G3/ACJ0H/XWT/0Ks34hXsepeB7G 9iPyTzRuPbKtxVr4eahZW/hKGOe8gicSOdryqp6+hNYNP2FvM64yX1tvyNHx9/yJeof7qf8Aoa1z Pwy1TT7DS71Ly9t7dmnBUSyBSRt966HxtdW914J1FreeOZQEBMbhgDvX0rhvBvgy08T2VxcXF1NC 0MgQCMDBGM96qmo+xalpqTWcvrUXBXdv8xPD0iS/E9ZI3Do93KVZTkEYbkV3nj7Vf7L8LThGxLdf uEx156/pmvPvC1qtl8RYLRGLLBcSRhj1IAYVc+KGq/a9cj09G/d2afN/vtyf0xWk4c1WK8jCnU5M PN9W7FDwHqTaR4pthLlIrxfKbPAOfun8wK7/AOJH/Im3H/XSP/0IV5hrWs22pNYNZ2htGs4Fhz5m 7dt6HoOetd/4p1NdY+GKX4PMvl7/AGYNhv1BoqRftIzsFGaVGpTvfS5J8K/+Rbn/AOvpv/QVrf8A Fn/Iqan/ANez/wAq5n4ZX1na+Hp0uLuCFjcsQskgU4wPWug8SXdtdeFNV+zXEU223bd5bhsce1c8 0/bfM7KTX1W3kzlPhJ11P/tn/wCzV6RXmPwsu7a1OpfabmKHd5ePMcLn73rXoseo2M+7ybyCTYpZ gkgbA9eKWIT9oysE17FI89+KmpmW5s9HiJO397Io7k8KP5/nU/wr1QmK80iU4aNvOjB9Dww/PH51 yFzr8c/jJtbuITPEtx5ixbsZVfujP4CpNH1+K08bJq0MZgt5pzvj3Z2q/UZ9s5/Cut0n7Lkt/wAO eeq69v7W/W3yPb6KQcjNLXmHuBRRRQAUUUUAFclrngC01zXP7Tku3i3bfMiVAQ+Pf3FdbRVRnKLv EidONRWkrmP4j8OweItKFhJIYArh0dVyVI9voaPDnh6Lw3pTWME5lLOXMrKAST7e2K2KzdavH062 jvdxEUMg81R/EpBA/wDHitDm1Hl6DjRjKpdLUwtH+H1rpmsnU7i9a+c7iUliGCzdT/OtDxD4RsNe sFtgEs2SQOJYohnoRj9apx6jqawvFJM0lxYmOOYLhfMd5Bjrx9zH/fVSXN9fzSvGVnhb7aI/KjmR WC+Tuxu6deaTryb5r6mqy+KThpb/AIYil8CrN4Xh0KTVJTHDP5qS+UMgc/LjPqTWR/wqO1/6C8v/ AH5H+Nb13qF5p8k7mZzbRWSb95DNE7b8PkdeQAfz7Vcu3lm/suI3csCzAmR42ClsJnrj1q1iKi2Z nLL6bs2vz6K5mWfgSGz8NXuiLfyMl44cy+WAVxjtn2q/4W8MR+GLSe3junuBNIHyyBccYqmdelQW e+6YrEC07CMnzVLlFJIGBwC3boKfLNLYwX3/ABMbppGuRbQs537MqpLAAckAsah15NNNmscAoyTt qtFv3ILHwFDZeJv7cGoSO/mvL5RjAHzZ4zn3ptt8P7ePxEdZur97tzK0rRPEApJz79s/pWuNSe40 S1uo3Ku00SScY53hWGD+NJpk0i3phubqSaWVWdcOrRkAjlQOV6jg1Xt59zH6jBJu2z/ETXfC9hrW mPZeXHaszBlliiXcpBrMi8CLH4Yn0FtUkeGWUSq5iGU6ZGM98VdW5lNvcXR1JlmPnqLc7cDZuxgd QRgHPeq1neX6RuJJZ0w9sCs8iux3uMkED7pBx9QalVpJWRq8DGTcna+xi/8ACpLU/wDMXm/78j/G tfSfAkOk6TqWnpfySDUECM5jAKYB6DPPWrY8+2e8YX9zJ5d3DEokcEBWMZPb/aP50+1v/KhbULnU WJKys9scEDaTwo6gjAHvmreIqPRszWX0o+9Ffn1RzX/CpLX/AKC83/fkf41f0v4dR6Ul6INVl3Xd uYC3lAFASCSOfbH41oafq00q20MtyWlW6CysyFNytGzAYIHAOR/wGujBDDIII9RT+sVJLcieBpUp fD+ZzPhvwNY+HzOzyC9abABliHyAZ6dfWmeJPAdjr88MyTfYWiUqRFEMOM5Hp711VFL2s+bmvqT7 CnycltCvY272ljBbSTGdoowhkIwWwMZxViiis9zVKysFFFFAwooooAKKKKACmvGkiFJEV1PUMMin UUARmCIliYkJYgsdo5I6E/TFMms7W4UrPbRShm3EOgOTjGfrip6KB3aIUtbeOMxpBGqFdhUIMFee MenJ/OieztbmNY7i2ilRPuq6BgPpmpqKA5ne9yMW8KoyCFArDawCjBGMYPtigQxBgwiQMDkHaM5x jP5cVJRQF2M8mLBHlpgtuI2jlvX60yK0toJHkht4o3f7zIgBb61NRQF2Qi0thK8ot4vMkG132DLD 0J704wQkgmJCQAAdo6A5H5GpKKAuxhhiOcxodxDH5RyR0P6D8qj+x2vmPJ9mi3yY3tsGW+p71PRQ F2Qz2drdf8fFtFL0++gbp06/U/nT4oo4I1jijWNF4CqMAfhT6KAu7WCiiigQUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --_004_C2BEDDCC0322FF4AAFDD7B4EB386E0DD82C75396NEWATLAStissatl_-- From nobody Sat Jun 30 13: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 E6E6B130EA4 for ; Sat, 30 Jun 2018 13:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfpmimAqHDTd for ; Sat, 30 Jun 2018 13:50:16 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 68FFB130E04 for ; Sat, 30 Jun 2018 13:50:16 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id bi1-v6so6083109plb.12 for ; Sat, 30 Jun 2018 13:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FbaNrhxyMLVLH+W60OZpl28dDasMPLRI6u46Ii9lM1Q=; b=jP6bO/PsMiAPf41JD7mKtxZQDgtNW8BSXlzgPs3qV3DVMjjVjqDb7pg/MmiHfYdgkH ySwGk8Y2fRvQdP1qP/3qyw3DIaIV85AazocqPB2173QUKh+YpNd5tCHmhCKgoZxqTcbI o5yOXKdSgxQTHKPto3Pwxg3YtRAT/NQuBAsjHrovP31YpKeG3Ps3AFbNuXOQgZj3Z3Jt RgVpFnfhWud9QMlCTOM8qp4FceVnXFTCunupOguaACeUBrgMZtTs7SlqJXVjskZKzEee V9JlMRZvhNBo3W7/NLI5rUi8UxMB42jA55zvvBhTmxTa42RQxR92KR+n/aM7Qsf8gOWD Mv0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FbaNrhxyMLVLH+W60OZpl28dDasMPLRI6u46Ii9lM1Q=; b=XjxD0MRl5nv1UpDcLc2aqda1l5Pxon3FuSVgdD5L4wtMYf+DRL4e4fnLXUfcKlp1JV cs1bltSEhoxreo+Vm/sA61TocnHX+fXPrQopZMJJxA6PuRtMA4q2Z4zSPuCm33QduJrl jicNT6xAjhNPI2b64opsvKtBNpS/zOKuFM2UHEVgDyQi4fVr1k7KKgCeZScUnYIkLukx vDHkA0FXpv7T1KarVW7iOQAE9rxuO42FUYSfJLtyH2HttD/OPN2Mt+KRDvP1s8+2Pudn XZLK2Jn9ZL35VdILo7uEzjjM9TMdLggNT+wUUIzYsnDik3zw8NL0ir3558PmlwI54GPi guNw== X-Gm-Message-State: APt69E2Ejjwe4mtpbk3SAMwiyaeCXhALcthHcayKpZau+XP/TA2har0V gCbyJtQ4fxnh+kKHzHutvA/eYQ== X-Google-Smtp-Source: ADUXVKINK+RGziI9RB58JB8OpyADQzWa25GCRx38PCZlnDJjc/0l14IyZr+whi0D1NrMYHTaOhFkaw== X-Received: by 2002:a17:902:b589:: with SMTP id a9-v6mr20226290pls.140.1530391815702; Sat, 30 Jun 2018 13:50:15 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id l28-v6sm4540609pfi.4.2018.06.30.13.50.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jun 2018 13:50:14 -0700 (PDT) To: v6ops@ietf.org References: <057742AA-226E-44F8-819E-C865D7F58758@gmail.com> From: Brian E Carpenter Message-ID: Date: Sun, 1 Jul 2018 08:50:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <057742AA-226E-44F8-819E-C865D7F58758@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 20:50:18 -0000 On 30/06/2018 19:16, Fred Baker wrote: >> Time to dump dual-stack networks and get on the IPv6 train - with LW4o6 https://news360.com/article/460267064 > > > IPv6 Jon the press. Thinking about this as we approach IETF 102, where IPv4 overlaid on or translated to IPv6 is on the agenda. It's a typical journalistic headline that over-simplifies something that's rather more subtle. There's no need to "dump" dual stack in situations where it's the best solution, and there's nothing wrong with coexistence for the next 20 years in situations where it's the simplest option. Also, of course, hosts that use IPv4-as-a-service over an IPv6-only link *are* dual stack hosts. But then, that's The Register for you. Brian
    On Tue, Jun 12= , 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wr= ote:

    You don=E2=80=99t need RFC7050 neither DNS64, you can use P= CP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional= advantages to the operator to control many related aspects (see section 3 = of RFC7225).

    =C2= =A0

    1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = If the operator wants to enable 464xlat: they shou= ld hand out a DNS64 to the CPE.

    2.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 If the operat= or wants to disable=C2=A0464xlat: they should NOT hand out a DNS64 to the C= PE.

    Thi= s doesn=E2=80=99t work, because the operator may be using RFC7225 instead o= f RFC7050. You need to try both in that case, and you aren=E2=80=99t provid= ing a =E2=80=9Cpriority=E2=80=9D to a possible list of mechanisms, which is= what RFC8026 does.


    = But it's the same problem again: what's the use case for this DHCPv= 6 option? An operator that's using RFC7225 has an easy way to tell the = CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So th= is is already possible today.
    =C2=A0=C2=A0

    3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>If the operator uses 464xlat, they= should not allow the user to change the DNS server.

    =C2=A0

    =C2=A0

    Let=E2=80=99s be realistic. Y= ou can=E2=80=99t =E2=80=9Cforce=E2=80=9D the customer to avoid changing the= DNS =E2=80=A6


    On an= operator-managed CPE, you can. On a user-managed CPE, you can't. But o= n such a CPE you probably shouldn't be disabling 464xlat. If the user w= ants to use it, it's their CPE, right?