From nobody Mon Dec 2 00:14:30 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8412022A for ; Mon, 2 Dec 2019 00:14:28 -0800 (PST) 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, SPF_HELO_NONE=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 0NoM10z0vXmt for ; Mon, 2 Dec 2019 00:14:27 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F083F120154 for ; Mon, 2 Dec 2019 00:14:26 -0800 (PST) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:50c5:bfc9:5d0d:5b13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id B3F4F4E11B06 for ; Mon, 2 Dec 2019 08:14:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 02A0F2453B28 for ; Mon, 2 Dec 2019 09:14:23 +0100 (CET) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 2 Dec 2019 09:14:23 +0100 References: To: "v6ops@ietf.org" In-Reply-To: Message-Id: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 08:14:28 -0000 > On 30 Nov 2019, at 21:14, Ron Bonica = wrote: >=20 > draft-smith-v6ops-local-only-addressing I believe Townsley or was it Vyncke described a security model, where a = device by default would only accept incoming connections on link-local = or ULA addresses. The device would have a global address that could be used for outbound = connections, e.g. software updated. Can't find or recall exactly where they described this model. Best regards, Ole= From nobody Mon Dec 2 03:45:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E32912024E for ; Mon, 2 Dec 2019 03:45:05 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vQQyQ3lSDxHD for ; Mon, 2 Dec 2019 03:45:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEE112022D for ; Mon, 2 Dec 2019 03:45:02 -0800 (PST) Received: from [192.168.3.69] (unknown [190.192.64.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6FE3885357; Mon, 2 Dec 2019 12:44:59 +0100 (CET) References: Cc: Ron Bonica , "v6ops@ietf.org" To: Mark Smith From: Fernando Gont Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <00f88b83-86f0-3249-e6bb-6dafb535a3ef@gont.com.ar> Date: Mon, 2 Dec 2019 08:30:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 11:45:05 -0000 Mark, Here are my comments: * Meta: I find it valuable to explore different ways of leveraging IPv6 addressing capabilities. In a way, it's a shame that given the lack of advice we have in this area, hosts/application are doing, at best, sub-optimal use of it. * Things that I think that are missing: + It would seem to me that your document should somehow that CPEs and DHCPv6 servers advirtise/lease ULAs, in addition of global addresses/prefixes? -- otherwise, it will be more unlikely that these devices get to configure ULAs + You might clarify that ULAs *might* be reachable from other networks if not properly filtered at the border. + IIRC this one was discussed at the last IETF meeting: how would e.g. automatic updates work? + The document should analyze why "only local" vs. "configure all, but do not allow incomming comunications" * Specific comments: > By default, a Local Only Address device MUST only configure Link- > Local and non-global IPv6 addresses, currently Unique Local Addresses > [RFC4193], on its network interfaces. You might want to clarify the terminology esp in the context of RFC8190. > By default, if there are no ULA prefix PIOs in the received RAs, or > no ULA prefix PIOs with the A flag set, the Local Only Addresses > device MUST only configure IPv6 Link-Local addresses on its network > interface. The text might be misleading/mis-interpreted: normally, at point you process RAs with PIOs, you have already configured link-locals. (the text might be interpreted like you configure them when there are no ULA prefixes with the A bit set). > By default, if there are ULA prefix PIOs that do not have the A flag > set, they MUST be processed per standard RA PIO processing for other > flags. For example, a PIO for a ULA prefix, with the A flag unset, > and the L or on-link flag set, is still processed, and is asserting > that the specified ULA prefix is on-link. I'd omit this para -- you are not changing the current state of affairs. > If the Configure All IPv6 Addresses configuration switch is enabled, > then the Local Only Addresses device MUST process all IPv6 RA PIOs > received for SLAAC address configuration, per [RFC4862], from that > point in time onwards. Same here. So I'd rephrase as ""If... normal processing of RAs takes place, honoring all prefixes" or the like. > > By default, a Local Address Only device MUST NOT accept any upper > layer connections from any global IPv6 addresses. s/upper layer/transport layer/? > An application may attempt to overcome this global IPv6 address > constraint by constructing packets itself that contain a global IPv6 > address source address. T Not sure what this means.... the app crafting IPv6 pckets? Thanks! Cheers, Fernando -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Mon Dec 2 11:55:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1C12003F for ; Mon, 2 Dec 2019 11:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0aPVh8DJyNC for ; Mon, 2 Dec 2019 11:55:32 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF57D120018 for ; Mon, 2 Dec 2019 11:55:32 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id s10so398617plp.2 for ; Mon, 02 Dec 2019 11:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iFZdC3IB2rWqn5T+meR9cJ6hJMGPSwmBAjz84XLmwbA=; b=Qkq0iLlf/WmfeBNP64hDQhrMUPL1wqD9CN3JhYWqXrL71K08vQPrzOb9VI/JbtxJuM WOR3+L+ivdu/W5wdzhn1LKlD5TkxsjNhV2d0DVuTHFv2Q7r19BeZvoCilx58fBoG7R2T MwcYMZ//bSVF6zg4twvElMbA5pKIEiL0KgueAw4kCXQzt88K4Y5oCQeU2EvJlbOjbh86 0x8LQZMFn1lincht7q5NbfZiA5I0NBdlTqKgLcjbiM9Nf+89hGbACTHkV6RkgxmOZ+nS EHbZeIK8YtYWLrzRzDooisWp9OHc2mBouwN6RNw1EfNaYnMF1gT9e4RX50YWfIdKrhZm 8lNA== 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=iFZdC3IB2rWqn5T+meR9cJ6hJMGPSwmBAjz84XLmwbA=; b=WCkxLE9Geb+oYM1nLP90CrtmCmtm2sl60GZ6cPe7F9/mXV4hk7PfTVHrm3uvkToTZt SNyGyMPeIFpjyZAmjBt82xsskOPC8t2vLyFWJMMDo92fkY3KHUzYKzjn9UxQ3RSVcE7+ ThBeMW/2SQZJIFuvgIXYV6wi+SsvIxrOMU8c9KApt3dPhQ6sA8T0yWZ8XqlYxV6pNPvk EH13l38QTlfzvEjdRtH8yqqwfObTk+cDOstHLi2abMqcgzYhbNO21A9KEsRXXaIBCVB0 RrpFErhkDix5E9ak28L2tFybnRg1f8epxplVSR1s60iHre0wXTVAsVDFkoyRtLLeqOeV v5ww== X-Gm-Message-State: APjAAAXezC5eZYjZwg5nsnvxphVrxTScHWVu/1VhBuRccqtdxjqft7Or 56sVvj9ViwlzIDP+5roDLVLxrn6D X-Google-Smtp-Source: APXvYqyKlkYRz0afdh6VD/tai/hYjiZg/LMT1kRwQukvuLjy74oCyeD5DFTgib/81vkx0NP4Mi1j1g== X-Received: by 2002:a17:90b:4391:: with SMTP id in17mr911519pjb.33.1575316532370; Mon, 02 Dec 2019 11:55:32 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::100b? ([2600:8802:5900:13c4::100b]) by smtp.gmail.com with ESMTPSA id s11sm390824pgo.85.2019.12.02.11.55.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 11:55:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Fred Baker In-Reply-To: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> Date: Mon, 2 Dec 2019 11:55:30 -0800 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6CF0CF5C-7E72-4E21-A476-3A5A65DBF7FA@gmail.com> References: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 19:55:35 -0000 I think you're thinking of an opec draft by Michael Behringer, = https://tools.ietf.org/html/rfc7404. In essence, it suggests that = routers only talk with each other and their local hosts using link-layer = addressing in the "destination" address.=20 To my way of thinking, forcing that for all sessions means that one = cannot access a device from a system that it is not directly connected = to. Michael's proposal was in essence to prevent attacks on routers, = permitting them to white-list network management devices and exclude = pretty much everything else. Doing that for hosts would make the network = pretty useless, I suspect.=20 > On Dec 2, 2019, at 12:14 AM, Ole Troan wrote: >=20 >=20 >=20 >> On 30 Nov 2019, at 21:14, Ron Bonica = wrote: >>=20 >> draft-smith-v6ops-local-only-addressing >=20 > I believe Townsley or was it Vyncke described a security model, where = a device by default would only accept incoming connections on link-local = or ULA addresses. > The device would have a global address that could be used for outbound = connections, e.g. software updated. > Can't find or recall exactly where they described this model. >=20 > Best regards, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 2 13:33:15 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3312008C for ; Mon, 2 Dec 2019 13:33:13 -0800 (PST) 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, SPF_HELO_NONE=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 ZFC6zNhYj3qs for ; Mon, 2 Dec 2019 13:33:11 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FD2120018 for ; Mon, 2 Dec 2019 13:33:11 -0800 (PST) Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D0F024E11AFF; Mon, 2 Dec 2019 21:33:09 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 888012462FE9; Mon, 2 Dec 2019 22:33:06 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ole Troan In-Reply-To: <6CF0CF5C-7E72-4E21-A476-3A5A65DBF7FA@gmail.com> Date: Mon, 2 Dec 2019 22:33:06 +0100 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> <6CF0CF5C-7E72-4E21-A476-3A5A65DBF7FA@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:33:14 -0000 Hi Fred, > I think you're thinking of an opec draft by Michael Behringer, = https://tools.ietf.org/html/rfc7404. In essence, it suggests that = routers only talk with each other and their local hosts using link-layer = addressing in the "destination" address.=20 >=20 > To my way of thinking, forcing that for all sessions means that one = cannot access a device from a system that it is not directly connected = to. Michael's proposal was in essence to prevent attacks on routers, = permitting them to white-list network management devices and exclude = pretty much everything else. Doing that for hosts would make the network = pretty useless, I suspect.=20 No it wasn't that one. It was very much along Mark's lines of increasing security by = controlling reachability and scope of addressing to end hosts. Perhaps it was just something he talked about when Eric and he did = advanced-security. Regardless, seems like a fine idea. Devices that have no business being = on the Internet, should as Mark proposes by default not have a global = address. Now you might argue, are there really any such device. Cheers, Ole >=20 >> On Dec 2, 2019, at 12:14 AM, Ole Troan wrote: >>=20 >>=20 >>=20 >>> On 30 Nov 2019, at 21:14, Ron Bonica = wrote: >>>=20 >>> draft-smith-v6ops-local-only-addressing >>=20 >> I believe Townsley or was it Vyncke described a security model, where = a device by default would only accept incoming connections on link-local = or ULA addresses. >> The device would have a global address that could be used for = outbound connections, e.g. software updated. >> Can't find or recall exactly where they described this model. >>=20 >> Best regards, >> Ole >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Dec 2 16:13:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7462C1200E0 for ; Mon, 2 Dec 2019 16:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhgffzcvAYCv for ; Mon, 2 Dec 2019 16:13:41 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193D3120058 for ; Mon, 2 Dec 2019 16:13:41 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id y206so748393pfb.0 for ; Mon, 02 Dec 2019 16:13:41 -0800 (PST) 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=sDSl8mQ/vio/aA0xhaVEBAWLLzKBsfBF7OyyeSOo3u0=; b=XoPc2vSVaMlgi4bwqQQpbAFYF9u8WdVS5bB6dX+iuhRFhnwPbIv+J6OrGVX4/AO83J bTG+GtB28MDvZ1R5IvDZs+vkAw5g1aC3UPd5SU5hBzy0fW4PhCWszK9+ZlnHxYd0x0YN HH5BgqwUrNBS2BVhYF1USq1Far3+owBnJf3aFkGTdfgAWgKKclL/XL9pISdQpcrLN6Cu 4bz2siSqvkzv9iuaYWQoMf6kmQaBC1/rbqw0UhbRQ0BU8oSZVcZWYP4gM+vZ5ZwkCcs4 cy/9UOBZTpMBa5AC6vlnR6K3cbCBsO4hw0D46EGsFuj5qu/85l4Sv6YvkoBdYtYdlx8F fGNQ== 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=sDSl8mQ/vio/aA0xhaVEBAWLLzKBsfBF7OyyeSOo3u0=; b=jofFsVF+eO43Pdrv4ATlXUH+6pb+8o/dl7szEBecoUUuXCtrGASyh6beqqLC76Wd0V 3pglWndBWG/FbGNe2bA6xzd2FW7C87xOnKDfWMsTImH8HR4VPQ+vrBG1xyhkfB3Ye1OW V67lnm8THkbq+LY6ORrILp4A7+DP0TxAxp+zL9OhH1Ab+L4sBYEsjEeP9kkfYCw+jFc2 Sy3bE3A6YG504QTAothvcphPQq7Fq0XpMebz0k+fhquHJsfgMVWY8fpdt7sj06lZRsJB pzo3T/NSK4HrX5SddWm0wZ3K9DOU/fEsIabsMyPG7szBmteEFhsWN6VlFN4T7xoAoQzE z8yQ== X-Gm-Message-State: APjAAAVO7Z6cUcGBXrw03drS9q46Avid085t8W1VPX3iDJOuDgjGpCT+ ONKn9SRjTNlur2SmvYRmT4sAdWNc X-Google-Smtp-Source: APXvYqxgIsiuhfhCc9dORS80D1v9mEerO2YVG4m36POIclbnxjZh8Sc9XC7l4Be+XiyMgEsLw5eYMQ== X-Received: by 2002:a62:be0e:: with SMTP id l14mr1527600pff.117.1575332020115; Mon, 02 Dec 2019 16:13:40 -0800 (PST) Received: from [130.216.37.136] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.136]) by smtp.gmail.com with ESMTPSA id h128sm646520pfe.172.2019.12.02.16.13.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 16:13:39 -0800 (PST) To: v6ops@ietf.org References: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> <6CF0CF5C-7E72-4E21-A476-3A5A65DBF7FA@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 3 Dec 2019 13:13:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 00:13:43 -0000 On 03-Dec-19 10:33, Ole Troan wrote: > Hi Fred, > >> I think you're thinking of an opec draft by Michael Behringer, https://tools.ietf.org/html/rfc7404. In essence, it suggests that routers only talk with each other and their local hosts using link-layer addressing in the "destination" address. >> >> To my way of thinking, forcing that for all sessions means that one cannot access a device from a system that it is not directly connected to. Michael's proposal was in essence to prevent attacks on routers, permitting them to white-list network management devices and exclude pretty much everything else. Doing that for hosts would make the network pretty useless, I suspect. > > No it wasn't that one. Well, there's always https://tools.ietf.org/html/rfc4864#section-3.2 And of course we punted on https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02 Brian > It was very much along Mark's lines of increasing security by controlling reachability and scope of addressing to end hosts. > Perhaps it was just something he talked about when Eric and he did advanced-security. > > Regardless, seems like a fine idea. Devices that have no business being on the Internet, should as Mark proposes by default not have a global address. > Now you might argue, are there really any such device. > > Cheers, > Ole > >> >>> On Dec 2, 2019, at 12:14 AM, Ole Troan wrote: >>> >>> >>> >>>> On 30 Nov 2019, at 21:14, Ron Bonica wrote: >>>> >>>> draft-smith-v6ops-local-only-addressing >>> >>> I believe Townsley or was it Vyncke described a security model, where a device by default would only accept incoming connections on link-local or ULA addresses. >>> The device would have a global address that could be used for outbound connections, e.g. software updated. >>> Can't find or recall exactly where they described this model. >>> >>> Best regards, >>> Ole >>> _______________________________________________ >>> 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 Dec 2 16:42:51 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A71200E9 for ; Mon, 2 Dec 2019 16:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3GFICdUPkKJ for ; Mon, 2 Dec 2019 16:42:47 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AE312008F for ; Mon, 2 Dec 2019 16:42:47 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id s18so791390pfm.4 for ; Mon, 02 Dec 2019 16:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=My5gn/CLxKvBR/FIaL7u0yT2mlySX1fYvP/zF3o3FcM=; b=rrDBmqLAXP6mrafRfTfvyHSsOuYqzPMzl2JaBhkSrGhypUGuHmEVa1olTJ1nwAxvrA dVHUMJdc3N99VT0SPZq2tdmXDS/XeGa2YlgVOVmDtYVMpweCQouP9nuKqJWkZ0oci3qR 6OkxtmgjCai6nwgvRHmxW76eD8kcAsy2Eit+87UdeYakqIhZU/VlTS30mWvPNR5Mr9FL eY7xjP5Xr5m6PFEZVEYAcYpx1ZONzzkW1F9VmqbNznK6bR5mbA2wDE3Oi+USTrtl3AuP U9TCNEJ7blgoQVPwgVkSZI2v3Z2DvlJEh6/L736Bt8LigW/6IfwmgmYRQx2gPm+bGpbd Pibg== 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:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=My5gn/CLxKvBR/FIaL7u0yT2mlySX1fYvP/zF3o3FcM=; b=f2yaWWd56+p+zF3XeJeYMMP88Tw7uU14IquzHn9k7zDcDdXxrYA0z8BPtneRnHcb/b Mp5A/pODzX4MDT7mZh/w9QH+H/8h360ljh46e5Bgfs1pzAZTy562cl5jSu63NKip952O Z7DqEYqj/ks3xomQnOOm0OmOkOuXCeReuH3UaLblbu2zOf7w8ZgUGTeFQLQizOZleJk7 sx1P0Hebq762q0hu7gNATpdrbSxyKHASqkbqUYZybEcEdy7sk7F32h+6icO5NufTk2nE 87U4gd+HGk4uyf3fdZH6v60NCMw6uE00BXTj6UNp/pKt7abi8SpKejv+RKkxMlizxUhy cAHw== X-Gm-Message-State: APjAAAV3lNrtRvlrVRp6Y2RuSk89J6rNpmz7H3PIEU9mfN54jTckLJjs hzpgI0pO1MjYd7T0BmTfvILQ3hvV X-Google-Smtp-Source: APXvYqx1DlAMoQqBr3lAYcgFzcEjk1GOlV2k5jnSTQu6py7u2DSWTbC3RK4Hd6KiyXQ8yWRKFdZhRg== X-Received: by 2002:a65:55cc:: with SMTP id k12mr2326351pgs.184.1575333766857; Mon, 02 Dec 2019 16:42:46 -0800 (PST) Received: from [130.216.37.136] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.136]) by smtp.gmail.com with ESMTPSA id w5sm766121pgb.78.2019.12.02.16.42.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 16:42:46 -0800 (PST) To: Mark Smith References: From: Brian E Carpenter Cc: "v6ops@ietf.org" Message-ID: <8c58a163-4b59-dd22-d742-360e681c0f66@gmail.com> Date: Tue, 3 Dec 2019 13:42:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 00:42:49 -0000 A few somewhat random comments: 1. A nit, but a major nit: the use of the word "global". Repeat after me: ULAs are global scope addresses. They are explicitly defined as having global scope in RFC4193. Also repeat after me: ULAs are not globally reachable addresses. They are explicitly forbidden to be routed globally by RFC4193. Yes, this could be confusing; that's why we have RFC8190. But each occurrence of "global" in the draft needs to be reviewed, and if appropriate, replaced by either "with global scope" or "globally reachable". For example, the last sentence of the Abstract should be: "This memo proposes that these types of devices refuse to configure and use globally reachable IPv6 Internet addresses by default." 2. > 2. Default Local Only Addresses > > By default, a Local Only Address device MUST only configure Link- > Local and non-global IPv6 addresses, currently Unique Local Addresses > [RFC4193], on its network interfaces. That will fail if the router doesn't announce a ULA prefix. What do you want the default behaviour to be in that case? OK, I see that you cover this point later under SLAAC but it seems to me that it is a general that point should be covered here. And I think your recommendation is broken from a practical point of view: if a device is installed on a routed network that does not announce a ULA prefix, limiting it to link-local is simply broken as it prevents the devices from being accessed by devices on other subnets. So I think the only practical proposal is that if and only if both ULA and globally reachable prefixes are announced, the device should configure only a ULA. > 5. Permitted Incoming and Outgoing Connections > > By default, a Local Address Only device MUST NOT accept any upper > layer connections from any global IPv6 addresses. This is a case where s/global/globally reachable/ is essential. I agree with it, although default settings in many CE routers will already do this. You probably need to discuss "call home" scenarios, which many vendors want to include in their products and which clearly need globally reachable addresses. Finally, I think there are points mentioned in https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-4.2 and even in RFC4864 that should be considered. Regards Brian From nobody Tue Dec 3 06:57:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00D12022A for ; Tue, 3 Dec 2019 06:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OnvMY-hLpp1 for ; Tue, 3 Dec 2019 06:57:33 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4A81201E5 for ; Tue, 3 Dec 2019 06:57:32 -0800 (PST) Received: from [192.168.3.69] (unknown [190.192.64.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 627FD860CE; Tue, 3 Dec 2019 15:57:29 +0100 (CET) To: Brian E Carpenter , v6ops@ietf.org References: <8237CDA6-DF99-43BB-8FFD-FC06179F5C75@employees.org> <6CF0CF5C-7E72-4E21-A476-3A5A65DBF7FA@gmail.com> From: Fernando Gont Autocrypt: addr=fernando@gont.com.ar; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <66d3fa8a-ca35-8f14-3ebc-fc81f0531f14@gont.com.ar> Date: Mon, 2 Dec 2019 22:32:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 14:57:35 -0000 On 2/12/19 21:13, Brian E Carpenter wrote: > On 03-Dec-19 10:33, Ole Troan wrote: >> Hi Fred, >> >>> I think you're thinking of an opec draft by Michael Behringer, https://tools.ietf.org/html/rfc7404. In essence, it suggests that routers only talk with each other and their local hosts using link-layer addressing in the "destination" address. >>> >>> To my way of thinking, forcing that for all sessions means that one cannot access a device from a system that it is not directly connected to. Michael's proposal was in essence to prevent attacks on routers, permitting them to white-list network management devices and exclude pretty much everything else. Doing that for hosts would make the network pretty useless, I suspect. >> >> No it wasn't that one. > > Well, there's always https://tools.ietf.org/html/rfc4864#section-3.2 > > And of course we punted on https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02 It's a shame that work in this area hasn't been pursue whether in this document, or elsewhere. Similarly, we did: draft-gont-6man-address-usage-recommendations-, which has broader scope. At the end of the day, we have all these different IPv6 address sorts but nodes/apps don't leverage them due to lack of appropriate advice. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Dec 3 10:52:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28CE12010D for ; Tue, 3 Dec 2019 10:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 42bel-1W7t6b for ; Tue, 3 Dec 2019 10:52:36 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C50F12000F for ; Tue, 3 Dec 2019 10:52:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB3IqYDI046517 for ; Tue, 3 Dec 2019 19:52:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 23BF82081B7 for ; Tue, 3 Dec 2019 19:52:34 +0100 (CET) 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 1A5F3208160 for ; Tue, 3 Dec 2019 19:52:34 +0100 (CET) Received: from [10.11.240.16] ([10.11.240.16]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB3IqX4K014336 for ; Tue, 3 Dec 2019 19:52:33 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <7b5e9190-1439-711d-2b0d-530ab1d4e70e@gmail.com> Date: Tue, 3 Dec 2019 19:52:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 18:52:39 -0000 Le 30/11/2019 à 21:14, Ron Bonica a écrit : > Folks, > > Each week between now and IETF 107, we will review and discuss one draft > with an eye towards progressing it. > > This week, please review and comment on > draft-smith-v6ops-local-only-addressing. I have read it, thanks for the pointer. We have such a setting with a convoy of three IP/V2V autonomous cars; we only have ULAs and LLs in there, even though I hope one day GUAs will reach them. Where draft says fc::/7 for ULA it is wrong, or am I again fooled by bits; shouldnt that rather be fc00::/7? The configuration option Configure All IPv6 Addresses SHOULD be on by default. > By default, if there are no ULA prefix PIOs in the received RAs, or > no ULA prefix PIOs with the A flag set, the Local Only Addresses > device MUST only configure IPv6 Link-Local addresses on its network > interface. ... and me who wanted to put fe80::/10 in PIOs :-( > changed > from enabled to disabled, earlier it says 'ommited' too, so there might be a problem for programmer to distinguish between the latter two. Alex > >                                                              Fred and Ron > > > Juniper Public > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Dec 3 16:47:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429EC120058 for ; Tue, 3 Dec 2019 16:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiZ7WIuI8BaJ for ; Tue, 3 Dec 2019 16:47:08 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3B512000F for ; Tue, 3 Dec 2019 16:47:08 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id 6so2469060pgk.0 for ; Tue, 03 Dec 2019 16:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1C1ruyrHFY/lbq/TIf4M1/ynd9ldVH0f3lLUYaD2iXM=; b=KnNuC1vwdP1f2dSxgDhsjNbPJQcnSNe48nqom4Kfs7J2+anRpHJbC2hyyeGQgmBFbM t2hZSoxKSxf7yrN+rys6kYf9Gsw5ScfGFclPoM9KmlUF1ZvWJZqLOGAKwMH6pzsAhWMg +V5eTx90lK+hgm3EgXvXs9iid9T+KrAd4WPVH1uubfSj9VmXj7W3XdC8c7BmAdpK1f+t 26bvG/pZJKCq9EVkJxmyoA0nztAcjtecX3+0hJ+8UKx0l5rRSGL0uaDV5N5M4SHjEm9J ewcIU/KMxs2a8M3GSBnQvtqIWOl2R9/O3/OLH+k9ObEae1d+1cYoS30/LhyqZ1TfjEhi BgNg== 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=1C1ruyrHFY/lbq/TIf4M1/ynd9ldVH0f3lLUYaD2iXM=; b=TC2WDDj8NU7/Dn3f/9uEsobNoEAY7TKJ/rpREc8MxIZQaeZaqGfI1effv3RfMaoh9q rHM2weE6Dtly6Uw7E2v4VPz7pVCUnyCzkdDn7MB5e4wbkdq5R6CcBvdHhk+Nd1CgM/ab K4L0NdPW81+4RmvinbePC9nGwzlRzez/KMAitMh5Qlelj17SAp8F0T2S2P2rRHKnBvPo dR+n3IkfvruZeyDiPZbJKyPdftDsbumZNHsKM2sXcIAf/Qz7+vjmFLgixNe5CAT/hqRe c6MPy5rzQjkD9wHjIcHdDKA9w0+trx8nCg97A0eoOnHeyzS3JbvE5NKjIZoQDMYvpdmm oDrA== X-Gm-Message-State: APjAAAXKWjsYdKpWoqgQvPEFn/b4zFqRYZrfwBc1XQNRdZUrv8Kmni8/ lkWPYdJ15dTSsM6zdhf6RisWyA4y X-Google-Smtp-Source: APXvYqw9EccmGni70Wtogi2tcG5cDiGxWTNgJmKSVHb/A28yts/O0RSLg+CuA9+aDOEp+XMG1YbZcA== X-Received: by 2002:aa7:8396:: with SMTP id u22mr762272pfm.137.1575420427283; Tue, 03 Dec 2019 16:47:07 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::1010? ([2600:8802:5900:13c4::1010]) by smtp.gmail.com with ESMTPSA id q11sm4987801pff.111.2019.12.03.16.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Dec 2019 16:47:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Fred Baker In-Reply-To: <7b5e9190-1439-711d-2b0d-530ab1d4e70e@gmail.com> Date: Tue, 3 Dec 2019 16:47:05 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <24602A48-0454-4B0E-B95B-292FC1E9486A@gmail.com> References: <7b5e9190-1439-711d-2b0d-530ab1d4e70e@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 00:47:10 -0000 > On Dec 3, 2019, at 10:52 AM, Alexandre Petrescu = wrote: >=20 > Where draft says fc::/7 for ULA it is wrong, or am I again fooled by = bits; shouldnt that rather be fc00::/7? Yes= From nobody Wed Dec 4 04:09:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666D120802; Wed, 4 Dec 2019 04:09:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voiarJ_w9TL8; Wed, 4 Dec 2019 04:09:24 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC4D120104; Wed, 4 Dec 2019 04:09:21 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id g15so6837986qka.8; Wed, 04 Dec 2019 04:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/5+mcuNP+ydlmj7HKs1W5EhLg50jHS3zjz5o2m+Sqf8=; b=IE5S0HG6r4uYVm6+FonWbpBAMVZK4I4cfBrSnywlDMJEAnpmeZAcoOn4BjxMSflWyy Qedgh8CARElY+rX378iTitpVY41h97d7f+ASwJrPekyPLNtQIZme7h6lxT4H2Z3rMqvZ bzazXzNlk4pDV/Du8+Hl41aiAaxplinCYhW8GZw8AqAZMTXkD3IRbBh6L2VatsIvpJxx jMrM5JHkqpUaLn45MtDVQMYZFeu3p/wOXlj2ci/kjjq47IEVxfRQDtuOXG/eu/g6vGfD pxeyZDfdKhAmpaE8NTrnZzfdSQ8QTwTw7FyUY01aU5CyuMsy3RZCZhCHP5/fMSP+aB9J ckmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/5+mcuNP+ydlmj7HKs1W5EhLg50jHS3zjz5o2m+Sqf8=; b=Lkz1rPf3pA6+m1fseEQqTRheZ/t3JSK8vGSQfZbNooM+z5dR+mDQzkiXrWE6Ufkdiw JMVzf+fMTX9L1wGopJp544/8qeNOnpjRh9FN0tjrqGSHBZey6ZCqLhz+eBz8mxkt+X+b R3Tza4eeY13V5wzk6Yxi00xrT0iXbWMyHdedoIsZ2jpH3RSpW6JhG27U9/GmG/ovrIdL eLlKgPb+FxEQylTdmWJNctuUHkEI8GAOB9XXlqDZ76z45BJP4Re00OHon/cZiPWw7bBt cqy0hW26WjPXzKiXdYM9LFM3UyyGOnq3PnDtcjlHn1ycpWpqKnxsqtSsgo2O/4tHajfw J0Ng== X-Gm-Message-State: APjAAAXlRcc8tCTPz3qFACE4M8Yx2MixpK5wQbf/BR6hTK4aCTD08qjk vAwwRsEB4XexzaexVAChK1lymN1XLqzhV0Px16cmdEMJ X-Google-Smtp-Source: APXvYqzNyLQnDpAxjXu+/WiEE/iGvBi2s0Qn9STUprjkorZOD64gHPw2GY8gK0eG+wbxvlO6NpeBzzLCJEZH9NsQXM4= X-Received: by 2002:a37:7686:: with SMTP id r128mr1424260qkc.277.1575461360058; Wed, 04 Dec 2019 04:09:20 -0800 (PST) MIME-Version: 1.0 From: Jen Linkova Date: Wed, 4 Dec 2019 23:09:08 +1100 Message-ID: To: dhcwg@ietf.org Cc: V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 12:09:25 -0000 Hello, One of the biggest issue in deploying IPv6-only LANs is how to do it incrementally, when some hosts work just fine in NAT64 environment while some legacy devices still need IPv4. Doubling the number of network segments (having an IPv6-only and dual-stack segments of each type) is an operational nightmare. So it would be just awesome if all devices can co-exist in the same network segment and hosts capable of operating in IPv6-only environment do not consume IPv4 addresses. So here is the draft proposing a new DHCPv4 option to help saving IPv4 addresses and deploying IPv4-as-a-service: Name: draft-link-dhc-v6only Revision: 00 Title: IPv6-Only-Preferred Option for DHCP Document date: 2019-12-04 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only Abstract: This document specifies a DHCP option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining a IPv4 address if the network provides IPv6 access. Any comments/suggestions/reviews are highly appreciated! Adding v6ops@ to Cc: as the problem is related to operating IPv6-only networks. Thank you! -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 05:31:39 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07BE12011E; Wed, 4 Dec 2019 05:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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_NONE=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=mork.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQfXLsOmXLTu; Wed, 4 Dec 2019 05:31:30 -0800 (PST) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4374120816; Wed, 4 Dec 2019 05:31:29 -0800 (PST) Received: from miraculix.mork.no ([IPv6:2a02:2121:2c8:26c5:b15d:7b70:572:cc53]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id xB4DVNT4031099 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Dec 2019 14:31:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1575466285; bh=xhW1IhRuzDb+2S11lEAq+ILKsI3AWcdHr+TLnJn2hW4=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=nS7+b1+8ID8/xtXcYsfxHvtag7ShFUzcIeecZzHDY783TyLFXvYXkpBw+TZSEPBBQ LMyV7HlbCSXYFZyqXPC56RmXSm42/hpHX+OIFHHEM4wTNNCQWuM0ZRy2bAbv6Ik3+d AfGCuWVR40rU68+M0JbjiOvpmr4lPOXkxlqU2pyQ= Received: from bjorn by miraculix.mork.no with local (Exim 4.92) (envelope-from ) id 1icUkP-0002tB-V2; Wed, 04 Dec 2019 14:31:17 +0100 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Jen Linkova Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Organization: m References: Date: Wed, 04 Dec 2019 14:31:17 +0100 In-Reply-To: (Jen Linkova's message of "Wed, 4 Dec 2019 23:09:08 +1100") Message-ID: <8736e0gqu2.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.101.4 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 13:31:33 -0000 Jen Linkova writes: > Hello, > > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. Doubling the number of > network segments (having an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all > devices can co-exist in the same network segment and hosts capable of > operating in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > addresses and deploying IPv4-as-a-service: > > Name: draft-link-dhc-v6only > Revision: 00 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-04 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6on= ly > "While IPv6-only capable devices might use a heuristic approach to learning if the network provdes IPv6-only functionality and stop using IPv4 if it does, it might be practically undesirable. One important reason is that when a host connects to a network, it does not know if the network is IPv4-only, dual-stack or IPv6-only. To ensure that the connectivity over whatever protocol is present becomes available as soon as possible the host usually starts configuring both IPv4 and IPv6 immidiately. If hosts were to delay requesting IPv4 until IPv6 reachability is confirmed, that would would penalize IPv4-only and dual-stack networks, which does not seem practical. " Why can't the client just release the IPv4 address when it finds it has IPv6 connectivity? This would also avoid the problems you introduce when the network falsely claims IPv6 support. Bj=C3=B8rn From nobody Wed Dec 4 05:56:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03412012E; Wed, 4 Dec 2019 05:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIq2dKkKdjNm; Wed, 4 Dec 2019 05:56:36 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 65C7F1200FE; Wed, 4 Dec 2019 05:56:36 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 47SgPZ4vW8z7v1Z; Wed, 4 Dec 2019 14:56:34 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 47SgPZ38MMzCqkn; Wed, 4 Dec 2019 14:56:34 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([fe80::7873:1668:636f:52c%21]) with mapi id 14.03.0468.000; Wed, 4 Dec 2019 14:56:34 +0100 From: To: =?utf-8?B?QmrDuHJuIE1vcms=?= , Jen Linkova CC: "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVqqcpBSACla8F1kqXnj5CuxCeX6ep+w8Q Date: Wed, 4 Dec 2019 13:56:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> In-Reply-To: <8736e0gqu2.fsf@miraculix.mork.no> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 13:56:39 -0000 SGkgQmrDuHJuLCANCg0KQmxpbmRseSByZWxlYXNpbmcgdGhlIElQdjQgYWRkcmVzcyB3aGVuIGFu IElQdjYgY29ubmVjdGl2aXR5IGlzIGF2YWlsYWJsZSBpcyBwcm9ibGVtYXRpYyBiZWNhdXNlIHRo ZSBob3N0IGRvZXMgbm90IGtub3cgaWYgYSBOQVQ2NCBmdW5jdGlvbiBpcyBhdmFpbGFibGUgZm9y IGEgZ2l2ZW4gbmV0d29yayBhdHRhY2htZW50LiBBIGhvc3QgdGhhdCBkaXNjb3ZlcnMgdGhlIHBy ZXNlbmNlIG9mIE5BVDY0IChiZWNhdXNlIGEgcHJlZjY0IHdhcyBkaXNjb3ZlcmVkKSBjYW4gc2Fm ZWx5IHJlbGVhc2UgYW55IGFzc2lnbmVkIElQdjQgYWRkcmVzcy4gTm8gYWRkaXRpb25hbCBzaWdu YWwgaXMgbmVlZGVkIGluIHN1Y2ggY2FzZS4NCg0KSmVuLCBkbyB5b3UgaGF2ZSBhIGNhc2Ugd2hl cmUgeW91IHdhbnQgdG8gZGVwbG95IElQdjYtb25seSBob3N0IHdpdGhvdXQgYW5ub3VuY2luZyBw cmVmNjQgdG8gdGhhdCBob3N0PyANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+IERlwqA6IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBCasO4cm4gTW9yaw0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDQgZMOp Y2VtYnJlIDIwMTkgMTQ6MzENCj4gw4DCoDogSmVuIExpbmtvdmENCj4gQ2PCoDogZGhjd2dAaWV0 Zi5vcmc7IFY2IE9wcyBMaXN0OyBkcmFmdC1saW5rLWRoYy12Nm9ubHlAaWV0Zi5vcmcNCj4gT2Jq ZXTCoDogUmU6IFtkaGN3Z10gSVB2Ni1Pbmx5IFByZWZlcnJlZCBESENQdjQgb3B0aW9uDQo+IA0K PiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyaXRlczoNCj4gDQo+ID4gSGVsbG8s DQo+ID4NCj4gPiBPbmUgb2YgdGhlIGJpZ2dlc3QgaXNzdWUgaW4gZGVwbG95aW5nIElQdjYtb25s eSBMQU5zIGlzIGhvdyB0byBkbyBpdA0KPiA+IGluY3JlbWVudGFsbHksIHdoZW4gc29tZSBob3N0 cyB3b3JrIGp1c3QgZmluZSBpbiBOQVQ2NCBlbnZpcm9ubWVudA0KPiA+IHdoaWxlIHNvbWUgbGVn YWN5IGRldmljZXMgc3RpbGwgbmVlZCBJUHY0LiBEb3VibGluZyB0aGUgbnVtYmVyIG9mDQo+ID4g bmV0d29yayBzZWdtZW50cyAoaGF2aW5nIGFuIElQdjYtb25seSBhbmQgZHVhbC1zdGFjayBzZWdt ZW50cyBvZiBlYWNoDQo+ID4gdHlwZSkgaXMgYW4gb3BlcmF0aW9uYWwgbmlnaHRtYXJlLiBTbyBp dCB3b3VsZCBiZSBqdXN0IGF3ZXNvbWUgaWYgYWxsDQo+ID4gZGV2aWNlcyBjYW4gY28tZXhpc3Qg aW4gdGhlIHNhbWUgbmV0d29yayBzZWdtZW50IGFuZCBob3N0cyBjYXBhYmxlIG9mDQo+ID4gb3Bl cmF0aW5nIGluIElQdjYtb25seSBlbnZpcm9ubWVudCBkbyBub3QgY29uc3VtZSBJUHY0IGFkZHJl c3Nlcy4NCj4gPiBTbyBoZXJlIGlzIHRoZSBkcmFmdCBwcm9wb3NpbmcgYSBuZXcgREhDUHY0IG9w dGlvbiB0byBoZWxwIHNhdmluZyBJUHY0DQo+ID4gYWRkcmVzc2VzIGFuZCBkZXBsb3lpbmcgSVB2 NC1hcy1hLXNlcnZpY2U6DQo+ID4NCj4gPiBOYW1lOiAgICAgICAgICAgZHJhZnQtbGluay1kaGMt djZvbmx5DQo+ID4gUmV2aXNpb246ICAgICAgIDAwDQo+ID4gVGl0bGU6ICAgICAgICAgIElQdjYt T25seS1QcmVmZXJyZWQgT3B0aW9uIGZvciBESENQDQo+ID4gRG9jdW1lbnQgZGF0ZTogIDIwMTkt MTItMDQNCj4gPiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFn ZXM6ICAgICAgICAgIDkNCj4gPiBVUkw6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWxpbmstZGhjLXY2b25seS0wMC50eHQNCj4gPiBTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluay1kaGMtdjZvbmx5 Lw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGluay1kaGMtdjZvbmx5LTAwDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluay1kaGMtDQo+IHY2b25seQ0KPiA+DQo+IA0K PiAgICJXaGlsZSBJUHY2LW9ubHkgY2FwYWJsZSBkZXZpY2VzIG1pZ2h0IHVzZSBhDQo+ICAgIGhl dXJpc3RpYyBhcHByb2FjaCB0byBsZWFybmluZyBpZiB0aGUgbmV0d29yayBwcm92ZGVzIElQdjYt b25seQ0KPiAgICBmdW5jdGlvbmFsaXR5IGFuZCBzdG9wIHVzaW5nIElQdjQgaWYgaXQgZG9lcywg aXQgbWlnaHQgYmUgcHJhY3RpY2FsbHkNCj4gICAgdW5kZXNpcmFibGUuICBPbmUgaW1wb3J0YW50 IHJlYXNvbiBpcyB0aGF0IHdoZW4gYSBob3N0IGNvbm5lY3RzIHRvIGENCj4gICAgbmV0d29yaywg aXQgZG9lcyBub3Qga25vdyBpZiB0aGUgbmV0d29yayBpcyBJUHY0LW9ubHksIGR1YWwtc3RhY2sg b3INCj4gICAgSVB2Ni1vbmx5LiAgVG8gZW5zdXJlIHRoYXQgdGhlIGNvbm5lY3Rpdml0eSBvdmVy IHdoYXRldmVyIHByb3RvY29sIGlzDQo+ICAgIHByZXNlbnQgYmVjb21lcyBhdmFpbGFibGUgYXMg c29vbiBhcyBwb3NzaWJsZSB0aGUgaG9zdCB1c3VhbGx5IHN0YXJ0cw0KPiAgICBjb25maWd1cmlu ZyBib3RoIElQdjQgYW5kIElQdjYgaW1taWRpYXRlbHkuICBJZiBob3N0cyB3ZXJlIHRvIGRlbGF5 DQo+ICAgIHJlcXVlc3RpbmcgSVB2NCB1bnRpbCBJUHY2IHJlYWNoYWJpbGl0eSBpcyBjb25maXJt ZWQsIHRoYXQgd291bGQNCj4gICAgd291bGQgcGVuYWxpemUgSVB2NC1vbmx5IGFuZCBkdWFsLXN0 YWNrIG5ldHdvcmtzLCB3aGljaCBkb2VzIG5vdCBzZWVtDQo+ICAgIHByYWN0aWNhbC4gIg0KPiAN Cj4gDQo+IFdoeSBjYW4ndCB0aGUgY2xpZW50IGp1c3QgcmVsZWFzZSB0aGUgSVB2NCBhZGRyZXNz IHdoZW4gaXQgZmluZHMgaXQgaGFzDQo+IElQdjYgY29ubmVjdGl2aXR5PyAgVGhpcyB3b3VsZCBh bHNvIGF2b2lkIHRoZSBwcm9ibGVtcyB5b3UgaW50cm9kdWNlDQo+IHdoZW4gdGhlIG5ldHdvcmsg ZmFsc2VseSBjbGFpbXMgSVB2NiBzdXBwb3J0Lg0KPiANCj4gDQo+IA0KPiBCasO4cm4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRoY3dn IG1haWxpbmcgbGlzdA0KPiBkaGN3Z0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From nobody Wed Dec 4 06:40:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F9120817 for ; Wed, 4 Dec 2019 06:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cSEIZynhGGoI for ; Wed, 4 Dec 2019 06:40:22 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423E812012E for ; Wed, 4 Dec 2019 06:40:22 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id b15so6874820ila.7 for ; Wed, 04 Dec 2019 06:40:22 -0800 (PST) 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=pmiykR1sTifoy1tUhZmgtVWjjrDMqEeW5iSNIdUTR/I=; b=jYJI7bwKHhxCy59q/L/xKZHqphu/v1XJm42ewdREfY9jymNrQItLA9+Lon596iCfq7 SwDlz2If14x/5jM0auISahr5igeYRrKMUKQtkEcWuZvm9TFqEHoUIfuhBYqGfjXCt7TG IcaOWevbWzapa04j/G8KZ8jGZBbQ1nEgORAz/x1MUuanbMScHMRMJ6fjzjKHOuDeCWhq 7HBK7Lw9O8oFQDutqwMLZf/NUnV0cnpZO62hq+Of7WQwN0gZxhshwrIB0PJ5gT3pN0/1 Sc+nlF2MQEU6UNQueP81VuVSSc5EpppjDEsGE5wilk0qMmYsBLqb1I5VsG0FPJ31ZO/a 9VGg== 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=pmiykR1sTifoy1tUhZmgtVWjjrDMqEeW5iSNIdUTR/I=; b=ZveOHckxa0dIWea3m+y0ei0Dby2RT+D5ync9DgE1CXgJqYtVWpveaWyxXrU8Wqwnab f04cq7TWAVKF9mcX2uXutBrFua1VW6yDpVuuHqMRav2q4lodc8nfr4I+b/pKyaiASoZE trxLd5bWvXHLf9JK8KNpIpHir8W/o27pdvRPHTBI8PKWXscfpadQsRt3Oj1I5Fg8NdRU aVlPAaB669Kqh8kcro3rzXhIIqcg8LFgB7HlqDgDaq6fMStKOT8/hUkw73H9UUZx+Aao r/pbZuAyyIlsZ5gfxZIX1cvZkn5rn4pEBN6ZrU2B+6B0CcfOXcITqWFxGfwC1vuSjoz+ RPzg== X-Gm-Message-State: APjAAAVglxza34SG83V3yD+i54aZsW9x+pZ0+kWcE8qxovaUIacxx4eZ uFRWQ008LmJPgvFhi6B4L1vnoTyuzNBxF3YMLLlX1Q== X-Google-Smtp-Source: APXvYqwQX7HkK6w3ibmo+M6gqe/MiztZmiSu/QI5vsQeYjKBGWNvjN+XJeP8PtHv2moW3qjfuszOOBiWpNDYLWWiVCg= X-Received: by 2002:a92:6e09:: with SMTP id j9mr1373469ilc.178.1575470421229; Wed, 04 Dec 2019 06:40:21 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> In-Reply-To: <8736e0gqu2.fsf@miraculix.mork.no> From: Lorenzo Colitti Date: Wed, 4 Dec 2019 23:40:09 +0900 Message-ID: To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000d03cb00598e1caad" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 14:40:24 -0000 --000000000000d03cb00598e1caad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 4, 2019 at 10:31 PM Bj=C3=B8rn Mork wrote: > Why can't the client just release the IPv4 address when it finds it has > IPv6 connectivity? This would also avoid the problems you introduce > when the network falsely claims IPv6 support. > Doing this creates a bad user experience, because once an IPv4 address is assigned to the device, apps immediately start using it. At that point, taking the address away is disruptive, potentially causing user-visible errors. --000000000000d03cb00598e1caad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 4, 2019 at 10:31 PM Bj=C3=B8r= n Mork <bjorn@mork.no> wrote:
Why can't the client just release the IPv4 address when it f= inds it has
IPv6 connectivity?=C2=A0 This would also avoid the problems you introduce when the network falsely claims IPv6 support.

Doing this creates a bad user experience, because once an IPv4 addre= ss is assigned to the device, apps immediately start using it. At that poin= t, taking the address away is disruptive, potentially causing user-visible = errors.
--000000000000d03cb00598e1caad-- From nobody Wed Dec 4 07:05:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6212081D; Wed, 4 Dec 2019 07:05:05 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 DJrWA34awLkd; Wed, 4 Dec 2019 07:05:04 -0800 (PST) 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 A769812008C; Wed, 4 Dec 2019 07:05:03 -0800 (PST) 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 m1icWD6-0000JdC; Wed, 4 Dec 2019 16:05:00 +0100 Message-Id: To: v6ops@ietf.org Cc: Jen Linkova Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com In-reply-to: Your message of "Wed, 4 Dec 2019 23:09:08 +1100 ." Date: Wed, 04 Dec 2019 16:04:54 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:05:06 -0000 >Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > address if the network provides IPv6 access. > >Any comments/suggestions/reviews are highly appreciated! I wonder about the deployment scenario. Basically the draft assumes that an operator is running both a dual stack network and IPv4-as-a-service in the form of NAT64. The draft assumes a migration path to NAT64, so we can assume that the IPv4 in dual stack is behind NAT as well. In general, address shortage on a local network behind NAT is not a problem (RFC 1918 space is big enough). So the main motivation I can find for running NAT64 next to dual stack is to collect statistics. I wonder how many network would offer two ways to do IPv4 just to collect statistic on how many hosts can both do NAT64 and have been modified to send the new DHCP option, which does not benefit the host. From nobody Wed Dec 4 07:52:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A036412002E; Wed, 4 Dec 2019 07:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 Hl7cT2jtuZxQ; Wed, 4 Dec 2019 07:52:03 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9940D120025; Wed, 4 Dec 2019 07:52:03 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xB4Fpt3n036949; Wed, 4 Dec 2019 07:52:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=g2EURWenXaRWg2/+jnbG7d8VVzyTVStpaWqJ1EQa3Mk=; b=IPnkPLS4mzmCUkLMYmBOI5n/i4fLQ1qPjA9uOHmyKJD64oYz9fky7K8/dG37CiC14Fgr fl6NShcMnTTIuqpEOqoacsJBOgVksnY7BXwnuQddr950qU4AIq7A1Ezyb7FQ/lRnB+ok AWOsndxXqeswEqYiuJAbH3BewZoG1yc97AxTd1EcJmdi3C9rNiYnfRp6QEAw/xYJ4Sjm R2y76pR9CO9UmCA/KgP+yFd0hL8bvzP+Ds1s+3Wmhj/DPERAT3Cb3mg+Wr9pt2CtxqvH KvbqMGlATqsVmUuC8/J/SBP9PDFu1eGpTZkhQEZGYFsygcwqHBLQEpT5iU70a0dZTxMp iA== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2wkqy9hwwd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 04 Dec 2019 07:52:02 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1Z00MFIW2PSZ30@mr2-mtap-s01.rno.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1Z00L00VY83W00@nwk-mmpp-sz11.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST) X-Va-A: X-Va-T-CD: edc22c7821eb8520bdad23543016aae0 X-Va-E-CD: d3299f328e4d3e92a5daeb3eb183023b X-Va-R-CD: aefc5808c3e3aec3e91cdc4e147c91e7 X-Va-CD: 0 X-Va-ID: 8de9e9fc-c7c6-4672-ae2d-e4ba2a788ecc X-V-A: X-V-T-CD: edc22c7821eb8520bdad23543016aae0 X-V-E-CD: d3299f328e4d3e92a5daeb3eb183023b X-V-R-CD: aefc5808c3e3aec3e91cdc4e147c91e7 X-V-CD: 0 X-V-ID: cbdc32e8-84a8-436e-bc2b-7176a1c82b44 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-12-04_03:,, signatures=0 Received: from [17.234.58.39] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1Z00K97W2LMX40@nwk-mmpp-sz11.apple.com>; Wed, 04 Dec 2019 07:52:01 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: Date: Wed, 04 Dec 2019 07:51:46 -0800 Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-transfer-encoding: quoted-printable Message-id: References: To: Jen Linkova X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-04_03:, , signatures=0 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:52:06 -0000 Hi Jen, Thanks for posting this draft! I find it to be both a well-written = document, and a great solution. This will be particularly critical for networks that want to adopt = IPv6-only (read, NAT64), but can't easily ensure that *all* devices on = the network upgrade to support that. This concept of IPv6-mostly = networks is a good stepping stone! =3D) What we've seen in cellular = networks for NAT64 rollout has had hiccups, and an option like this to = smooth the transition would have been useful there. But without an = option like this, I don't see a good way for less-managed networks = (enterprise Wi-Fis, public Wi-Fis) to make the transition since they = can't guarantee what devices are on their networks. As a client OS vendor, I think this would be easy for the client hosts = to implement, and we'd likely see a scenario in which pretty quickly, = most modern mobile devices and laptops would support this, and we'd end = up with using v4 on networks only for more "legacy" devices. I'd certainly support this document going forward and being adopted. Best, Tommy > On Dec 4, 2019, at 4:09 AM, Jen Linkova wrote: >=20 > Hello, >=20 > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. Doubling the number of > network segments (having an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all > devices can co-exist in the same network segment and hosts capable of > operating in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > addresses and deploying IPv4-as-a-service: >=20 > Name: draft-link-dhc-v6only > Revision: 00 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-04 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > Status: = https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only >=20 >=20 > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > address if the network provides IPv6 access. >=20 > Any comments/suggestions/reviews are highly appreciated! >=20 > Adding v6ops@ to Cc: as the problem is related to operating IPv6-only = networks. >=20 > Thank you! > --=20 > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 4 08:10:23 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E16120025 for ; Wed, 4 Dec 2019 08:10:20 -0800 (PST) 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 OFNt9mpRER2Q for ; Wed, 4 Dec 2019 08:10:18 -0800 (PST) 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 494AF120019 for ; Wed, 4 Dec 2019 08:10:18 -0800 (PST) Received: from [192.168.1.135] (host-79-121-42-101.kabelnet.hu [79.121.42.101]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id xB4GA9H3059271 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 4 Dec 2019 17:10:14 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-101.kabelnet.hu [79.121.42.101] claimed to be [192.168.1.135] To: v6ops@ietf.org References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Wed, 4 Dec 2019 17:10:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------FBBEF7AC68976DAAB3256338" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 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.101; helo=[192.168.1.135]; 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] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 16:10:21 -0000 This is a multi-part message in MIME format. --------------FBBEF7AC68976DAAB3256338 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Med, 12/4/2019 2:56 PM keltezéssel, mohamed.boucadair@orange.com írta: > A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address. Maybe I'm misunderstanding something, but I do not agree. Unfortunately not all applications are compatible with NAT64. Please see our results in: S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the NAT64 IPv6 Transition Technology", /Proceedings of the 37th International Conference on Telecommunications and Signal Processing (TSP 2014)/, (Berlin, Germany, 2014. July, 1-3.) Brno University of Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383 Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf Best regards, Gábor --------------FBBEF7AC68976DAAB3256338 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Med,

12/4/2019 2:56 PM keltezéssel, mohamed.boucadair@orange.com írta:
A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address.

Maybe I'm misunderstanding something, but I do not agree. Unfortunately not all applications are compatible with NAT64. Please see our results in:

S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the NAT64 IPv6 Transition Technology", Proceedings of the 37th International Conference on Telecommunications and Signal Processing (TSP 2014), (Berlin, Germany, 2014. July, 1-3.) Brno University of Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf

Best regards,

Gábor

--------------FBBEF7AC68976DAAB3256338-- From nobody Wed Dec 4 09:29:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC7A120861 for ; Wed, 4 Dec 2019 09:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oCxfxBhwXVst for ; Wed, 4 Dec 2019 09:29:15 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11FE12085F for ; Wed, 4 Dec 2019 09:29:15 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id o11so86037pjp.9 for ; Wed, 04 Dec 2019 09:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cKKZqU1UDI9BnjbWttLAHkxA4tYLBKNLBQAvPHxLuIU=; b=Z3pP7s0+oyiUoIEJiRHcATbb5bh9qPCeQWufv9eR4mSjPFGrq+/9HzJ1Xf/UtEWZiU +6mSiJJH0TgVcbTqD/ZMho5HcnS080ZTk1Mw0ZMCP7V0iDCMQ+FwnnyWj3EVn6uxLA2z FgnHLVKfHOFkn6NZfgBZN8EuWSc4dNv6aEXeFn+2/JmXwlB9T/A8id15KYxSFrKsdN4A C85y40qLlELHubB8xAi1TpRFK9xW8F7Dh4OS3PqW1L/LLl0QXM4QDTAkYPHNH5oM9iJd XfTbGUbRNKwTz5n5O/vkO0YSpP7Qm3z76B768Jw36HhZZDp7P8I9gxAQ/Jed9wfsti3t IiFA== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=cKKZqU1UDI9BnjbWttLAHkxA4tYLBKNLBQAvPHxLuIU=; b=Nv5mSTk1rN42zEuvEOzeMgx2kw1iNEejiDel+lU+S9A8zF5jp46L1H+7F913zbXNOl nWv8locI5+1QDaDDMnvS/xZEWGRXZT7fcPqcFcn2hFSJn+/PjH2eS1AyZZSfvZPDxeEM pQ4OSU/75djrOBy1kOQapaTW0PlOaGErWDK0msXKpIz7htIbUHap8En0qHI9gF0tN25Z ZCETEwPtM7DB/F8l87LoC5Pckp33dAwx/x/E+v1PS4LrY+0+iw/SYMzy4sVe9OooR/kq nkg1Rb5Abm/Pgm8VCvUpoFbBP/oEjXN1bBHwKws8Ae/EoEtP50JejBZnnixKg+xMRJBS 70eA== X-Gm-Message-State: APjAAAWHLoe+8a+JaIZXF1F8OFZTyHzh/oRuRM9AhowDqrAH4DKE+rBh n+waE3m+0ZwbrPA29sgQDKrdMQ== X-Google-Smtp-Source: APXvYqzS2RYoZ9A3d4CeDQqeGVVWZEAfNwqtz7k1rLqLsLaMeLWt2Layx/pOW7FpwQcyqa7VSCzZOw== X-Received: by 2002:a17:90a:868b:: with SMTP id p11mr4514564pjn.60.1575480555106; Wed, 04 Dec 2019 09:29:15 -0800 (PST) Received: from ?IPv6:2600:380:8664:4dd7:b11c:5d0c:5041:fea9? ([2600:380:8664:4dd7:b11c:5d0c:5041:fea9]) by smtp.gmail.com with ESMTPSA id l13sm6756426pjq.18.2019.12.04.09.29.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2019 09:29:13 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 4 Dec 2019 09:29:12 -0800 Message-Id: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> References: Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List In-Reply-To: To: Jen Linkova X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 17:29:18 -0000 This is good in principle. The client behavior section should require the cl= ient to send a parameter request list and to specify the option code of the n= ew option in the list along with any other options it expects to get.=20 > On Dec 4, 2019, at 04:09, Jen Linkova wrote: >=20 > =EF=BB=BFHello, >=20 > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. Doubling the number of > network segments (having an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all > devices can co-exist in the same network segment and hosts capable of > operating in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > addresses and deploying IPv4-as-a-service: >=20 > Name: draft-link-dhc-v6only > Revision: 00 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-04 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6onl= y >=20 >=20 > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > address if the network provides IPv6 access. >=20 > Any comments/suggestions/reviews are highly appreciated! >=20 > Adding v6ops@ to Cc: as the problem is related to operating IPv6-only netw= orks. >=20 > Thank you! > --=20 > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Dec 4 09:48:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9812085B for ; Wed, 4 Dec 2019 09:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD_QmGEO6y7Y for ; Wed, 4 Dec 2019 09:48:32 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 2807D120853 for ; Wed, 4 Dec 2019 09:48:32 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 47SmY93V1wz5wCV; Wed, 4 Dec 2019 18:48:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 47SmY92cC6z5vMq; Wed, 4 Dec 2019 18:48:29 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Wed, 4 Dec 2019 18:48:29 +0100 From: To: =?iso-8859-1?Q?Lencse_G=E1bor?= , "v6ops@ietf.org" Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVqr1cn+wfGkMdV0W9ROdx/HB9UKeqPf3x Date: Wed, 4 Dec 2019 17:48:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E2BB5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E2BB5OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 17:48:34 -0000 --_000_787AE7BB302AE849A7480A190F8B9330313E2BB5OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gabor, Please see inline. Cheers, Med ________________________________ De : v6ops [v6ops-bounces@ietf.org] de la part de Lencse G=E1bor [lencse@hi= t.bme.hu] Envoy=E9 : mercredi 4 d=E9cembre 2019 17:10 =C0 : v6ops@ietf.org Objet : Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Hi Med, 12/4/2019 2:56 PM keltez=E9ssel, mohamed.boucadair@orange.com =EDrta: A host that discovers the presence of NAT64 (because a pref64 was discovere= d) can safely release any assigned IPv4 address. Maybe I'm misunderstanding something, but I do not agree. Med: My assumption is what in the draft: the mode is explicitly set by a us= er. A DHCP client SHOULD allow a device administrator to configure IPv6-only preferred mode either for a specific interface (to indicate that the device is IPv6-only capable if connected to a NAT64 network via that interface) or for all interfaces. Clients not capable of operating in an IPv6-only NAT64 environment MUST NOT include the IPv6-only Preferred option in the Parameter Request List of any DHCP packets and MUST ignore that option in packets received from DHCP servers. Unfortunately not all applications are compatible with NAT64. Med: Sure. All the issues discussed in RFC6269 apply. Some of them can be s= olved: * bittorrent: https://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00 * SIP: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00 Please see our results in: S. R=E9p=E1s, T. Hajas and G. Lencse, "Application Compatibility of the NAT= 64 IPv6 Transition Technology", Proceedings of the 37th International Confe= rence on Telecommunications and Signal Processing (TSP 2014), (Berlin, Germ= any, 2014. July, 1-3.) Brno University of Technology, pp. 49-55. DOI: 10.11= 09/TSP.2015.7296383 Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP= -2014-AC.pdf Med: Thanks for the pointer. These issues are not specific to NAT64; many o= f them can be solved (see the pointers above, for example). Best regards, G=E1bor --_000_787AE7BB302AE849A7480A190F8B9330313E2BB5OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Gabor,

Please see inline.

Cheers,
Med

De : v6ops [v6ops-bounces@ietf.org] de la= part de Lencse G=E1bor [lencse@hit.bme.hu]
Envoy=E9 : mercredi 4 d=E9cembre 2019 17:10
=C0 : v6ops@ietf.org
Objet : Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

Hi Med,

12/4/2019 2:56 PM keltez=E9ssel, mohamed.boucadair@orange.com =EDrta:
A host that discovers the presence of NAT64 (b=
ecause a pref64 was discovered) can safely release any assigned IPv4 addres=
s.

Maybe I'm misunderstanding something, but I do not agree.

Med: My assumption is what in the draft: the mode is explicitly set by= a user.
   A DHCP client SHOULD allow a device administrator=
 to configure=0A=
   IPv6-only preferred mode either for a specific interface (to indicate=0A=
   that the device is IPv6-only capable if connected to a NAT64 network=0A=
   via that interface) or for all interfaces. 
   Clients not capable of operating in an IPv6-only =
NAT64 environment=0A=
   MUST NOT include the IPv6-only Preferred option in the Parameter=0A=
   Request List of any DHCP packets and MUST ignore that option in=0A=
   packets received from DHCP servers.

Unfortunately not all applications are compatible with NAT64.

Med: Sure. All the issues discussed in RFC6269 apply. Some of them can= be solved:


Please see our results in:

S. R=E9p=E1s, T. Hajas and G. Lencse, "Application Compatibility of th= e NAT64 IPv6 Transition Technology", Proceedings of the 37th International Conference on Telecommunications a= nd Signal Processing (TSP 2014), (Berlin, Germany, 2014. July, 1-3.) Br= no University of Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf

Med: Thanks for the pointer. These issues are not specific to NAT64; m= any of them can be solved (see the pointers above, for example).

Best regards,

G=E1bor

--_000_787AE7BB302AE849A7480A190F8B9330313E2BB5OPEXCAUBMA2corp_-- From nobody Wed Dec 4 10:22:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC31208C3; Wed, 4 Dec 2019 10:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 2lEKbyHvvOyZ; Wed, 4 Dec 2019 10:22:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D625012085B; Wed, 4 Dec 2019 10:22:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03D463818F; Wed, 4 Dec 2019 13:18:32 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5B0CEAAB; Wed, 4 Dec 2019 13:22:09 -0500 (EST) From: Michael Richardson To: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 18:22:13 -0000 --=-=-= Content-Type: text/plain Tommy Pauly wrote: > Thanks for posting this draft! I find it to be both a well-written document, and a great solution. As an author, thank you. I think that this document grew quickly from hallway discussion at IETF106. > As a client OS vendor, I think this would be easy for the client hosts > to implement, and we'd likely see a scenario in which pretty quickly, > most modern mobile devices and laptops would support this, and we'd end > up with using v4 on networks only for more "legacy" devices. A question that we had was whether or not hosts in a IPv6-mostly network should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts. The DHCPv4 option has a payload value that can be returned with information. Right now, it's a boolean: if the option exists the network is ready. We have considered two things: 1) We could put a time at which the host should recheck for v4. This avoids making mis-configuration of IPv6-mostly networks permanent. The question is not whether such a recheck timeout should exist (it must); but rather whether we should allow it to be configured in the option, or if we can just suggest some implementation local value. 2) Whether or not IPv4-LL (169.254.0.0) addresses should be configured or not. We could make this an option in the payload here as well. We wind up with four classes of v4-hosts: 1) IPv4-only legacy hosts which do not speak IPv6 at all. (The old printer in the corner, a whole plethora of stupid Web-Connected IoT devices) Some might not even have IPv4-LL addresses though! 2) Dual-Stack hosts do not understand this option. They have IPv4-LL and IPv6-LL addresses as well as IPv6 GUAs and ULAs, so they can talk to any host on the network. 3) Dual-Stack hosts which have an operational need for IPv4 that is not satisfied by NAT64, and which therefore either do not include this option, or for which the network is aware of their need, and does not answer with the option set. 4) Dual-Stack hosts which turn off their IPv4. Do they keep IPv4-LL so that they can talk to (1)? [5) IPv6-only capable hosts which never speak IPv4] -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3n+VEACgkQgItw+93Q 3WWLggf/cYfbk8hRhaBrlMmhXVQoSJoBNG2NGzCYns6fKUvTyw0emUcMFaHzLBgm 58gsowjfrhDvpaK9tWJ20yyoq6yWcWkTq2xCl1erfB0CdyiBzhbCwISCmwjwlljr RyYxx7flMawYg0I9IQTvd6S2LaK2H7YzdVhRmRmWWtH72diCjuyQHCZRcN8ksuEo 1lIWjj2HsxBByZVfo5deHe4PWn8bns816KIV0tFbb/4eCRhtAnkiQoW5T+PIwuWJ 8cGKnEWXMqay1gVcfX32tLUXdLJxMIk5g0WYxyvy6EnLfUQBNV7OVu5FclfVW2mM BFvaCJfe+Wfs0uwyviwq2Qv/GMtNBQ== =QnEr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 4 10:36:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938EA120936; Wed, 4 Dec 2019 10:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=CGWDhsb8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U9A/cHG8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKueO0gJKi9P; Wed, 4 Dec 2019 10:36:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CFC120949; Wed, 4 Dec 2019 10:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4796; q=dns/txt; s=iport; t=1575484576; x=1576694176; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8xvbEwEHuk9vDi8Wj54GG5Jd0SKsJkO9Q6Vfz7w0TKk=; b=CGWDhsb890HOy7KKQriExshzGzLPcd5PTRM2MX0ZOXtE8kEa37bdwWIJ Wo3Q53phth07iX/hPaukgAsKeHwE3rLbPnT+FWxE0hc/4feTZBWoODiu1 sUlHkgO0e2dys3Fc/f68lj6f9yC5Ra3PBYlAbso9SVcyOeN4KGNHmBHCR E=; IronPort-PHdr: =?us-ascii?q?9a23=3A/UwbyReHpXQxQEQJ/oB0AsrylGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeDtaz4SF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAADq++dd/49dJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBbQMBAQELAYFKJCwFbFggBAsqCoQhg0YDinqCX4lbjim?= =?us-ascii?q?BQoEQA1QJAQEBDAEBGAsKAgEBhEACF4F5JDcGDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVIBAQEBAgEBARAREQwBASwLAQQHBAIBCA4DBAEBAQICJgICAh8GCxUICAI?= =?us-ascii?q?EAQ0FCBqDAYJGAw4gAQIMpXoCgTiIYHWBMoJ+AQEFgTUBAwIOQYMCDQuCFwM?= =?us-ascii?q?GgQ4oAYUbhnsaggCBEUeCTD6CG0kBAQIBAYFHGoMOMoIskCGFc5d4QgqCLoc?= =?us-ascii?q?fiiCENpomjkqIQYIWj0wCBAIEBQIOAQEFgWgjgVhwFRohgmxQERRYjA6Dc4U?= =?us-ascii?q?UhT90AYEnjzABgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,278,1571702400"; d="scan'208";a="677802664" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Dec 2019 18:36:15 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xB4IaE8m015884 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2019 18:36:15 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 12:36:14 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 12:36:13 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 4 Dec 2019 13:36:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b3wZU/I4ohdxB7VE2X9aX8VNhia8uQdjU0bFJJtr8CxPuKbQFxz+ow72fV41slPvubEZFv2gHefCkEkvZ+cgbO7qsxRAmjMxlgIMV1iwNYMDVXBufSi8Wb9EA8xJ0fTrd7meq9yUpsLygmEL83gJSRmvfAI0cgYhLV2y5bdso31GhLhIEquqxNHjpDeCjQPhYt/EVLshsf7l8E9F3IqwRp6BjV3xChRvYyBnTZ57+3mwz4g45/JO0sqob/d30QyPXZQaHm852dflBIIPB5Zbi4FH0q0KBlCgdz+lUVDNiFJrWqvQX9tkCgqUoNXAHMYaQyU+5OselGMLD2BXWqfh1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8xvbEwEHuk9vDi8Wj54GG5Jd0SKsJkO9Q6Vfz7w0TKk=; b=ipfNoplMCTJXHLaro+SSoaCcUuJBBUaj1FGbi7qJir+1m2Dugg5CD875lGvUd+GpFI9Z+wMzEHDgFl6xjp3OkktdD1Vp1W2WoSyfrSA5CSuf+VYlPwNiyzFWNMuh2aWNWuFEO1Ey0ofVvlpwNr5+gL4RtLPlw0qiVTYAb77jAnBjx6fqOClkiPiiuDZnVMKlGUk8g8XgVg2a9s9ymutxbWxe1abktN/9jx+KkynRBZWSYMe+vMJyoAnY+YqiKGxEgQF9Q4ftRmu5hPSJyPDk78V6djjz1EV5/HzRve7bGSWErCl2neio/GxExvqt7nXXNKP+8kKcmWZq10vZ1I1aZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8xvbEwEHuk9vDi8Wj54GG5Jd0SKsJkO9Q6Vfz7w0TKk=; b=U9A/cHG89EPTeYPRpkGY0lbX3f7lz2W6dmVXSEOiVtLcfqrIpDmUCg/Fwr2dmRgXnBh275/GeTR+DztfObY2Gyjg/xq2uJHQY46zzKZ0e+R3lKUTBPnLY4qJiebWf7saPDvCZCGeJ/Ksb9yzxjG7kykNw2DaLJzLJdIutjqRw90= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3226.namprd11.prod.outlook.com (20.176.120.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.13; Wed, 4 Dec 2019 18:36:12 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2495.014; Wed, 4 Dec 2019 18:36:11 +0000 From: "Bernie Volz (volz)" To: Ted Lemon , Jen Linkova CC: "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVqshr5x+ephW0YkqsDNgBPunSMKeqSuoQ Date: Wed, 4 Dec 2019 18:36:11 +0000 Message-ID: References: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> In-Reply-To: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.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=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e00244a2-8d52-4750-b8da-08d778e8d642 x-ms-traffictypediagnostic: DM6PR11MB3226: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(199004)(189003)(13464003)(86362001)(8936002)(11346002)(3846002)(33656002)(229853002)(7696005)(6436002)(14444005)(6116002)(26005)(99286004)(76176011)(102836004)(478600001)(19627235002)(4326008)(6246003)(25786009)(53546011)(6506007)(66574012)(8676002)(55016002)(74316002)(7736002)(81156014)(81166006)(305945005)(2906002)(54906003)(186003)(5660300002)(66446008)(64756008)(110136005)(316002)(66556008)(71200400001)(14454004)(71190400001)(66946007)(9686003)(76116006)(66476007)(966005)(52536014)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3226; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NjXdj1f2H2woFdLrpaEJTml+rh/XT8je1Vg6evXovSm/2RN22dYSh6/Ec9HVDfTEbckD4V+0URy8ipfmCNS9pO77WS37c1khjhvKi6gO48u+aU6QXN+XjuzflI4JVZApooR0lwlAUbfo0z87ldpkjZXtiwTklHd7mIVGbnbvKAinAmKflQ/DL46raopHr24xO6gM/GkfOAhKZkfxERmsAUQ/TL2g2S8AdXl8h9A7QMQGyziCTleSE69s30TNqVlwx3kCgyLb9/jzVvMcFsmAK8w/aH0gIV7/mKMQdbBaD5C65iRNd/+wAyHtBttmrDwFvRaJzQlno/+3axpe1VE1kfq11DFxkrZvSXj6vHTl7htTiXvq1uvstJymutTOzZYybg0PBzhi4pUzd8+sNslAF3Nuh+W9QYAScov6L70Z87gy9It8CSump7oqPYovYtFFLq2oxISgnOs5Krp+/7eTrYdoF2DUh79IVPitex6jCBzV+WeTfB3JjE+oVoUHojtCpuafSTDAu+uCyJrd+0fMRwv0cbUdD/4OYX3v4OASFFk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e00244a2-8d52-4750-b8da-08d778e8d642 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 18:36:11.6498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rnQQC8uqjpCHeMijm60VJY/gn5JscszBEBYRpkvHLvzpbFnpKROLqHBvkkT0eRvN X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3226 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 18:36:20 -0000 VGhlcmUgaXMgYWxzbyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdGhlIFY2T05MWS1XQUlUIHRpbWUg dmFsdWUgdGhhdCB0aGUgY2xpZW50IHNob3VsZCB1c2UgYmUgcmV0dXJuZWQgaW4gdGhlIG9wdGlv biAtIGkuZS4sIHRoZSBvcHRpb24gc2hvdWxkIGJlIGEgNCAob3IgMikgb2N0ZXQgb3B0aW9uIHJl dHVybmluZyBhbiB1bnNpZ25lZCBpbnRlZ2VyIG9mIHRoZSB0aW1lLiBQZXJoYXBzIHJldHVybmlu ZyAwIGluZGljYXRlcyB0aGUgY2xpZW50IHNob3VsZCB1c2UgaXRzIGRlZmF1bHQgKHRodXMgdGhl IHZhbGlkIHZhbHVlcyB3b3VsZCBiZSAwIG9yIDMwMCA+PSB2YWx1ZSA8PSBtYXggKDg2LDQwMCBz ZWMsIDI0IGhvdXJzPykpLg0KDQpUaGlzIHdhcyBkaXNjdXNzZWQgd2hpbGUgZHJhZnQgd2FzIGlu IGRldmVsb3BtZW50IGJ1dCB3ZSBkaWRuJ3QgZW5kIHVwIHdpdGggYSBkZWNpc2lvbi4gU28sIHdv cnRoIGRpc2N1c3NpbmcgYSBiaXQgb24gbGlzdC4NCg0KDQpBIG1pbm9yIG5vdGUgYWJvdXQgdGhl IGRyYWZ0IHJlcXVlc3RpbmcgdXNlIG9mIChESENQdjQpIG9wdGlvbiBjb2RlIDEwOC4gUGVyIFJG QzM2NzkgdGhpcyB3YXMgaW4gdXNlIGFzIGEgInN3YXAgcGF0aCIgb3B0aW9uIGF0IHNvbWUgcG9p bnQsIHRob3VnaCBuZXZlciBwdWJsaXNoZWQgYXMgYSBkcmFmdC4gVGhhdCBpcyB3aHkgaXQgaXMg bWFya2VkIGFzICJSRU1PVkVEL3VuYXNzaWduZWQiIGFzIHRoZSBpZGVhIHdhcyB0byBOT1QgcmV1 c2UgdGhlc2Ugb3B0aW9uIG51bWJlcnMgdW50aWwgdGhlcmUgd2FzIGEgbmVlZCAoaS5lLiwgbm8g b3RoZXIganVzdCAidW5hc3NpZ25lZCIgb3B0aW9uIGNvZGVzIHdlcmUgYXZhaWxhYmxlKS4gV2hp bGUgSSBoYXZlIG5vIG9iamVjdGlvbiBpZiB0aGUgZHJhZnQgd2lzaGVzIHRvIHJlcXVlc3QgdXNl IG9mIHRoYXQgb3B0aW9uIGNvZGUsIEkganVzdCB3YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQgdGhl cmUgY291bGQgYmUgc29tZSBvdGhlciBjb25mbGljdGluZyB1c2FnZSBvdXQgaW4gdGhlIHdpbGQu DQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyA8 djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciA0LCAyMDE5IDEyOjI5IFBNDQpUbzogSmVuIExpbmtvdmEgPGZ1cnJ5 MTNAZ21haWwuY29tPg0KQ2M6IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0 Zi5vcmc+OyBkcmFmdC1saW5rLWRoYy12Nm9ubHlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZv cHNdIFtkaGN3Z10gSVB2Ni1Pbmx5IFByZWZlcnJlZCBESENQdjQgb3B0aW9uDQoNClRoaXMgaXMg Z29vZCBpbiBwcmluY2lwbGUuIFRoZSBjbGllbnQgYmVoYXZpb3Igc2VjdGlvbiBzaG91bGQgcmVx dWlyZSB0aGUgY2xpZW50IHRvIHNlbmQgYSBwYXJhbWV0ZXIgcmVxdWVzdCBsaXN0IGFuZCB0byBz cGVjaWZ5IHRoZSBvcHRpb24gY29kZSBvZiB0aGUgbmV3IG9wdGlvbiBpbiB0aGUgbGlzdCBhbG9u ZyB3aXRoIGFueSBvdGhlciBvcHRpb25zIGl0IGV4cGVjdHMgdG8gZ2V0LiANCg0KPiBPbiBEZWMg NCwgMjAxOSwgYXQgMDQ6MDksIEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT4gd3JvdGU6 DQo+IA0KPiDvu79IZWxsbywNCj4gDQo+IE9uZSBvZiB0aGUgYmlnZ2VzdCBpc3N1ZSBpbiBkZXBs b3lpbmcgSVB2Ni1vbmx5IExBTnMgaXMgaG93IHRvIGRvIGl0IA0KPiBpbmNyZW1lbnRhbGx5LCB3 aGVuIHNvbWUgaG9zdHMgd29yayBqdXN0IGZpbmUgaW4gTkFUNjQgZW52aXJvbm1lbnQgDQo+IHdo aWxlIHNvbWUgbGVnYWN5IGRldmljZXMgc3RpbGwgbmVlZCBJUHY0LiBEb3VibGluZyB0aGUgbnVt YmVyIG9mIA0KPiBuZXR3b3JrIHNlZ21lbnRzIChoYXZpbmcgYW4gSVB2Ni1vbmx5IGFuZCBkdWFs LXN0YWNrIHNlZ21lbnRzIG9mIGVhY2gNCj4gdHlwZSkgaXMgYW4gb3BlcmF0aW9uYWwgbmlnaHRt YXJlLiBTbyBpdCB3b3VsZCBiZSBqdXN0IGF3ZXNvbWUgaWYgYWxsIA0KPiBkZXZpY2VzIGNhbiBj by1leGlzdCBpbiB0aGUgc2FtZSBuZXR3b3JrIHNlZ21lbnQgYW5kIGhvc3RzIGNhcGFibGUgb2Yg DQo+IG9wZXJhdGluZyBpbiBJUHY2LW9ubHkgZW52aXJvbm1lbnQgZG8gbm90IGNvbnN1bWUgSVB2 NCBhZGRyZXNzZXMuDQo+IFNvIGhlcmUgaXMgdGhlIGRyYWZ0IHByb3Bvc2luZyBhIG5ldyBESENQ djQgb3B0aW9uIHRvIGhlbHAgc2F2aW5nIElQdjQgDQo+IGFkZHJlc3NlcyBhbmQgZGVwbG95aW5n IElQdjQtYXMtYS1zZXJ2aWNlOg0KPiANCj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhj LXY2b25seQ0KPiBSZXZpc2lvbjogICAgICAgMDANCj4gVGl0bGU6ICAgICAgICAgIElQdjYtT25s eS1QcmVmZXJyZWQgT3B0aW9uIGZvciBESENQDQo+IERvY3VtZW50IGRhdGU6ICAyMDE5LTEyLTA0 DQo+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAg ICAgIDkNCj4gVVJMOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbGluay1kaGMtdjZvbmx5LTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluay1kaGMtdjZvbmx5Lw0KPiBIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpbmstZGhjLXY2b25seS0w MA0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1saW5rLWRoYy12Nm9ubHkNCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhIERIQ1Agb3B0aW9uIHRvIGluZGljYXRlIHRoYXQgYSBob3N0DQo+ ICAgc3VwcG9ydHMgYW4gSVB2Ni1vbmx5IG1vZGUgYW5kIHdpbGxpbmcgdG8gZm9yZ28gb2J0YWlu aW5nIGEgSVB2NA0KPiAgIGFkZHJlc3MgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXMgSVB2NiBhY2Nl c3MuDQo+IA0KPiBBbnkgY29tbWVudHMvc3VnZ2VzdGlvbnMvcmV2aWV3cyBhcmUgaGlnaGx5IGFw cHJlY2lhdGVkIQ0KPiANCj4gQWRkaW5nIHY2b3BzQCB0byBDYzogYXMgdGhlIHByb2JsZW0gaXMg cmVsYXRlZCB0byBvcGVyYXRpbmcgSVB2Ni1vbmx5IG5ldHdvcmtzLg0KPiANCj4gVGhhbmsgeW91 IQ0KPiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBtYWlsaW5nIGxpc3QN Cj4gZGhjd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaGN3Zw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Dec 4 11:53:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B7C120945 for ; Wed, 4 Dec 2019 11:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g57L7zzg8aJV for ; Wed, 4 Dec 2019 11:53:17 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3642D12093F for ; Wed, 4 Dec 2019 11:53:17 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id g4so228971pjs.10 for ; Wed, 04 Dec 2019 11:53:17 -0800 (PST) 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=ctMXuaWsoOqq1w7ue85GcGdmUB0/qzGAb5FSG8KEA6c=; b=bzzdTLsnEpLIcjhSsPeiuAYVHnefLTx+l0anN8EMNcJpYGLhQHhxbHRBkipIHyiTIr jJ1NZbAUbp3pNFAs89marsKRLEsSx79pl7FcqMz2W0G4y6VPYQmI0Vbvuka9DAKgZIoa hxO/+OTMIwjr/t8Y/AroueG9WU64pSEPkGnrwumPkqzeSPtDrbxZccfvjM+cHVCwFWCm RnnT68nRUHw3F2VhGEWMeXuaSejKAgiE4LBensDuCLc+3x0raH5olTkAYbjBNIZR6xX8 3YWrVRRMXPTJEKVK/t4ZbugTgVCvNhcVv23h7231hzhBq6SnxaGnQfXguyC7uzu15oKe IGRQ== 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=ctMXuaWsoOqq1w7ue85GcGdmUB0/qzGAb5FSG8KEA6c=; b=fQO0AtEYXIl5EaU0Q6sBv7w55U2rGjvtZKoPlN4pif72CxI3S+XHqdbhMnyXp1Mz3v OrHOFq59uyG/prHlbkoP/w9NPdsp6O3pcaIfy3n96KmwBSajgeU4MxhJrUpJggM3+e5+ etC2bOKTRcAXLkc7iToze5cmvHIp50OlvBLJe5EolIlu1Kk9W1cg9198HD5QeUL9/rDs gvovMnYjP9C3msS5poKnVkQdsVVMmFfttegDB5jR5UMx2PXusvKab1IjBFH4Zxg3mfuy j/rRuaUdfV0xBoJCvOUF4JOy4ZxTmeqv2aTEJUeWlMyXLN+arvBL8xpGcAPELPoyRH+a IQ7A== X-Gm-Message-State: APjAAAXbOpg7Wgedjju28KMtRs5fGFQO7XK3WZv4UzH1PtL16lHvRomi YfYyBudblgRqe/j2fNI1I1JY2JrX X-Google-Smtp-Source: APXvYqyU4sltcfOlgI3r0FB+p9oTSBjeVv1ANkxxV8cgFTnozuaHHWzJW9kQuZTj6n3aPI9bXBE9sw== X-Received: by 2002:a17:90a:8818:: with SMTP id s24mr5242993pjn.31.1575489196488; Wed, 04 Dec 2019 11:53:16 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id h26sm272578pfr.9.2019.12.04.11.53.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 11:53:15 -0800 (PST) To: v6ops@ietf.org References: <28594.1575483729@localhost> From: Brian E Carpenter Message-ID: <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> Date: Thu, 5 Dec 2019 08:53:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <28594.1575483729@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 19:53:19 -0000 As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoid IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell hosts to prefer IPv6 will also be accused of being an operational nightmare. Regards Brian On 05-Dec-19 07:22, Michael Richardson wrote: > > Tommy Pauly wrote: > > Thanks for posting this draft! I find it to be both a well-written document, and a great solution. > > As an author, thank you. > I think that this document grew quickly from hallway discussion at IETF106. > > > As a client OS vendor, I think this would be easy for the client hosts > > to implement, and we'd likely see a scenario in which pretty quickly, > > most modern mobile devices and laptops would support this, and we'd end > > up with using v4 on networks only for more "legacy" devices. > > A question that we had was whether or not hosts in a IPv6-mostly network > should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts. > > The DHCPv4 option has a payload value that can be returned with information. > Right now, it's a boolean: if the option exists the network is ready. > We have considered two things: > > 1) We could put a time at which the host should recheck for v4. This avoids > making mis-configuration of IPv6-mostly networks permanent. The question > is not whether such a recheck timeout should exist (it must); but rather > whether we should allow it to be configured in the option, or if we can > just suggest some implementation local value. > > 2) Whether or not IPv4-LL (169.254.0.0) addresses should be configured or not. > We could make this an option in the payload here as well. > > We wind up with four classes of v4-hosts: > > 1) IPv4-only legacy hosts which do not speak IPv6 at all. > (The old printer in the corner, a whole plethora of stupid Web-Connected IoT devices) > Some might not even have IPv4-LL addresses though! > > 2) Dual-Stack hosts do not understand this option. > They have IPv4-LL and IPv6-LL addresses as well as IPv6 GUAs and ULAs, so > they can talk to any host on the network. > > 3) Dual-Stack hosts which have an operational need for IPv4 that is not > satisfied by NAT64, and which therefore either do not include this option, > or for which the network is aware of their need, and does not answer with > the option set. > > 4) Dual-Stack hosts which turn off their IPv4. > Do they keep IPv4-LL so that they can talk to (1)? > > [5) IPv6-only capable hosts which never speak IPv4] > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Dec 4 12:21:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D9C12093F; Wed, 4 Dec 2019 12:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=buhVbZZR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PHUXpdVa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xhYGGlR8C58; Wed, 4 Dec 2019 12:21:49 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A23C120808; Wed, 4 Dec 2019 12:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1575490909; x=1576700509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zeiStX/euKrCU3ID/hSvmKQRFJdmD98mgss6Q+UsE/k=; b=buhVbZZR2V5JHBT/M8TeUVvpkgv8UmADPgY0LaFEVWEvqUBMdjcbm/31 Q5SjkKJfOZHcJHHADVDhSxL1ANs1TeB8Tdnk6Cm84dw4L33D5PiZlShMn XLLNXJHjUjWORQJLgqgGmlNTnuPU74LvLbc6l2o+FvUvl2aO1SjBLZbzm 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AVo7asRTc4VHrG/anOlyWZb5vHtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUANfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5NksAKh0olCc+BB1f8Kav0aCgoNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAQC+FOhd/4sNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgW0EAQELAYFKJCwFbFggBAsqCodnA4p6gl+YBIJSA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBhEACghAkNwYOAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQEDAQEQKAY?= =?us-ascii?q?BASwLAQsEAgEIDgMEAQEfECcLHQgCBAENBQgagwGCRgMuAQIMpgYCgTiIYII?= =?us-ascii?q?ngn4BAQWBOQIOQYJ/GIIXAwaBNgGFG4Z7GoIAgViCTD6CZAEBAgEBgUkYg0C?= =?us-ascii?q?CLI09iFeYOgqCLoY7ZI5WmiaOSohBkWICBAIEBQIOAQEFgWgjgVhwFRohgmx?= =?us-ascii?q?QERSMZoNzhRSFP3QBgSePMAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,278,1571702400"; d="scan'208";a="670544030" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Dec 2019 20:21:48 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xB4KLl91000745 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2019 20:21:48 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 14:21:47 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec 2019 15:21:46 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 4 Dec 2019 14:21:46 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EkclWdn5PqrKJQ4+3lxfNrZR2TvpGqJGqby70WVwGZh1h1sruVVRz21Ce2Liqb1skOFzazth+u4R4ZgjbAaybya8adtHft4QlJLO203XBMQ3K1al9+ZUDxBRmMCPKPypc++aJXb28ECRHLv9sq7fXQ0VUWWvRlK+KNk/MfJ48guFvhcRsXRxhMlcVX0umGGUE06TcBRke8+STr+4FHrwpqkqmX+ylrupiMjeyDMWsAxAYTBLNMQ/4C0eXXJ5n1eeeHjiTEd3UyKVEchXL+bs6pzHnK0ZfyIW2VB2LCCvnrg+bfJ5EcgVwlmNYHgl6jKXUsQga+9goPCHje0PIgJJrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u++daovVBX9NocYG3TXM3Yx5W2iTNLW4jRR9SbO36gw=; b=O/nz9c/4EPEa42CId26Qd0rE9MvtdbNpfatG0ToN5PSfpTexcWu0xRnfKwKlWQodhGG1fY3gG/eln+8xdD4MUZ5FPRPsYiQqxWcTqxGyYfoTXuCiiapijD3qqxKgGIs19sgG2MfG/BlPTC+PcbgLidcZFLSGn225Y2RU3mL6H5VpwZY475NhBNefUVnVM+6aS6/IdDFvYEgsa5qAMOec14b7UI2VziMySCsbU6m6E3ZYhogSDpFoiRNrfcnJUC7T64uBsRxO0gXFQdlZBwJOrwiG4FSK7Z7NfGpZ5kwB8U84gIOBqW9znV7Dq+SrZ2AaG1MpuPrmTiymozMjZe/41g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u++daovVBX9NocYG3TXM3Yx5W2iTNLW4jRR9SbO36gw=; b=PHUXpdVajtfSpeX8MrmRrWedrbASJuhA9Dn69mu+KxqkFY0VI+4auTt8eIMmETCdn/Hnxoqc1Ho0l0FF0JAaqrE//+f3zPdVVobH354FHeJpEHQ6abbegrC2SZJJaN/CwcXzoUQ3KfvMj6xsJx8L0aVh+LQqE14Ne5q8ASRITSA= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3164.namprd11.prod.outlook.com (20.176.120.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Wed, 4 Dec 2019 20:21:45 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2495.014; Wed, 4 Dec 2019 20:21:45 +0000 From: "Bernie Volz (volz)" To: Jen Linkova , "dhcwg@ietf.org" CC: "draft-link-dhc-v6only@ietf.org" , "V6 Ops List" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVqpuzpq5GW9sfF0KRMvO8RARyP6eqau3A Date: Wed, 4 Dec 2019 20:21:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b84ae4bd-9cc4-4f17-8431-08d778f7954c x-ms-traffictypediagnostic: DM6PR11MB3164: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(136003)(39860400002)(366004)(199004)(189003)(51444003)(13464003)(2501003)(110136005)(14444005)(8936002)(9686003)(74316002)(305945005)(55016002)(52536014)(6116002)(5660300002)(3846002)(54906003)(25786009)(11346002)(14454004)(478600001)(66574012)(99286004)(7736002)(186003)(53546011)(6246003)(19627235002)(8676002)(81166006)(26005)(86362001)(2906002)(102836004)(81156014)(71200400001)(7696005)(76176011)(6436002)(4326008)(76116006)(71190400001)(64756008)(66446008)(966005)(66476007)(66556008)(229853002)(6306002)(66946007)(316002)(6506007)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3164; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BqfgNKQFdXGGUJmzJ17Oto2RZ42HVqQclXJ8mr0Bl9DZ9yWJNx9i/dsxbhg+Srqv70TIPmkgWilKoZbl1O7j4nIV9tq6a5sGv9HrF6NYtI0EsIeCzcMVQqSsxMhuj5CuhKEtiM5bcP/QzAyH0WR6nGDDdpGJXkdQ+2+Bxz3k8N+m6suxKrkl8TJPUBXrPxDP8YP7rMnzMDPZSvae1e5r+lBG6/8UVHgK9KC/IjkxMti6WaftVa6y3K9I2k0aYdldInaNMCcljc1++1ZSPsYmjudONfTq/buKX7D1RZvCdNjYSIOvJhWgYNBfRLwYzmpuzsOvkDBnvbn3yQ7Hoe1X2sqGflYnBdYdeJ0c7m8NNjd4Nfo6bVjn0BNJb2L/Jp98wvQTRrNU5zxPNkiO3jnsOgCtiNRsywpF5TiGYztp7WapfZyHmgvWk7E8/5eDOQ8DM3P+yMJBuUzOhdGETYIHbOmTZCTyRFmttO/8AmHPnE7zBbXpXN2Ca003IE6iO7tcTut6/B15w3BkQt7Bt2HHPsC9G1aXLBSHp2m61RXhXWgyG4+f1VnGqpjjXoB4Sk2D x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b84ae4bd-9cc4-4f17-8431-08d778f7954c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 20:21:45.1600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: //RQ0PzTcFJgJu9V6ZvlEfILkOBlzTF4Xy5DNtsme2CFTf+lA4Of3vUV5h7tvKy1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3164 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:21:51 -0000 I think there is a typo in Section 2 (middle paragraph): Another benefit of using DHCPv4 for signalling is that IPv4 will be disabled only if both the client and the server indicate IPv6-only capability. It allows IPv6-only capable clients to turn off **IPv6** only upon receiving an explicit signal from the network and operate in dual-stack or IPv4-only mode otherwise. I think that "turn off IPv6" should be "turn off IPv4". Also s/signalling/signaling/. - Bernie -----Original Message----- From: dhcwg On Behalf Of Jen Linkova Sent: Wednesday, December 4, 2019 7:09 AM To: dhcwg@ietf.org Cc: draft-link-dhc-v6only@ietf.org; V6 Ops List Subject: [dhcwg] IPv6-Only Preferred DHCPv4 option Hello, One of the biggest issue in deploying IPv6-only LANs is how to do it increm= entally, when some hosts work just fine in NAT64 environment while some leg= acy devices still need IPv4. Doubling the number of network segments (havin= g an IPv6-only and dual-stack segments of each type) is an operational nightmare. So it would be just awesome if all devic= es can co-exist in the same network segment and hosts capable of operating = in IPv6-only environment do not consume IPv4 addresses. So here is the draft proposing a new DHCPv4 option to help saving IPv4 addr= esses and deploying IPv4-as-a-service: Name: draft-link-dhc-v6only Revision: 00 Title: IPv6-Only-Preferred Option for DHCP Document date: 2019-12-04 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only Abstract: This document specifies a DHCP option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining a IPv4 address if the network provides IPv6 access. Any comments/suggestions/reviews are highly appreciated! Adding v6ops@ to Cc: as the problem is related to operating IPv6-only netwo= rks. Thank you! -- SY, Jen Linkova aka Furry _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Dec 4 12:43:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0188120895 for ; Wed, 4 Dec 2019 12:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Lfh0DXNAGIqY for ; Wed, 4 Dec 2019 12:43:06 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9212C12004C for ; Wed, 4 Dec 2019 12:43:06 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id xB4Kh4Yq031041 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2019 20:43:04 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.foobar.org To: Brian E Carpenter Cc: v6ops@ietf.org References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> From: Nick Hilliard Message-ID: <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> Date: Wed, 4 Dec 2019 20:43:03 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.8 MIME-Version: 1.0 In-Reply-To: <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:43:08 -0000 Brian E Carpenter wrote on 04/12/2019 19:53: > As an ex-author of an ex-draft that suggested using IPv6 to tell > hosts to avoid IPv4, I'm curious to know whether a draft that > suggests using IPv4 to tell hosts to prefer IPv6 will also be accused > of being an operational nightmare. I haven't read the draft yet - and won't get to it for a couple of days - but am also curious about why this approach is better than the other way around :-) Nick From nobody Wed Dec 4 12:44:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943DF120895 for ; Wed, 4 Dec 2019 12:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-D5E6jhCxiJ for ; Wed, 4 Dec 2019 12:44:55 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912881200A3 for ; Wed, 4 Dec 2019 12:44:55 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id x7so405393pgl.11 for ; Wed, 04 Dec 2019 12:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E+GWXATTZCgUc3aSrrx/4orwGRaahQ3VXqO+J1RRil0=; b=WDe6nBgd+rSw69yKTYGqBKcTfHL3l3mDhWOXvjkh6gu0YwPEyDruh33DEyr1JBvIEV VqvM3PZwq2fS6VyyaIL66iW4Ax+cg5HSkzALtuI1JlTLIMxjlT3IvTli3ySKgc42j6FL 0m2AAnsAENrqQJG26kKjPddUREEpG0VPPAcfBahxx3pAzeebbKM79T4F8iTpUvvWhPy0 s6s1fGjh1mSCIcVkpRn8pCT2+HLghz+hS+stZT0wrwNyjhfeuoyIj3uqhnjlXcWuUrUz 5ViEEWbh79T9VlSog39Bw7K+3ENYzDXF4D6BSqxz8x5I+5eq+BU7+Xsgx3yHG/LskKet Sj4Q== 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=E+GWXATTZCgUc3aSrrx/4orwGRaahQ3VXqO+J1RRil0=; b=ZiBP6Tli71oLMDKPtw823VhC7rx1kIMBUc6Ia7aBOmN7/lWtqx9V9CIgwlimraTUiG DxV98kT92Z84ISHk5u9mYCNHkaUO3ilkAuBiJUcYAjSyMvRzsvrKUicTNXeV0s4GTKf1 2W8OyYjcSB+rScqZ5Y/iN7PwFqYQJjAYJmCwNkPQ1BqKWwByIncE0jjBBklD4wkIQOZ6 MdodrqynK40K+LrcsS/M5IZMwxKk7sbR3gZhgJ6XWNnXmaosIr9452LlLmurr3EtmnD2 dLOGZVaXbJmZtSYnvPFs+uww+lLTiuy0cjunlni3rJJyuvAu+cpM7p+AKFO4sV2x9jSp IKbA== X-Gm-Message-State: APjAAAUAqzQLTtDFfvg+zefdXP8Gpcom7em/BpJiIrkNlZ9IYYn4JFgl DJm7jZPgSUkya1NXvT6yIkU8WQ== X-Google-Smtp-Source: APXvYqy+YpuwTe1N6dqK9YtV6uQ1JgzL8sRVflamBrIS2DifLPn4ZNt/EmO+p8XSL7FtcHL/IEBBYQ== X-Received: by 2002:a62:447:: with SMTP id 68mr5427604pfe.70.1575492294832; Wed, 04 Dec 2019 12:44:54 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id t8sm9875213pfq.92.2019.12.04.12.44.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 12:44:54 -0800 (PST) From: Ted Lemon Message-Id: <446BE15A-16D3-4F7A-9508-3AAAB2D95FE0@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F78374D2-B8A8-4E60-8176-8E19FB7A0795" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Wed, 4 Dec 2019 12:44:52 -0800 In-Reply-To: <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> Cc: Brian E Carpenter , v6ops@ietf.org To: Nick Hilliard References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:44:58 -0000 --Apple-Mail=_F78374D2-B8A8-4E60-8176-8E19FB7A0795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 4, 2019, at 12:43 PM, Nick Hilliard wrote: > approach is better than the other way around :-) Because once the device knows it=E2=80=99s on an IPv6-only network, it = doesn=E2=80=99t have to keep trying to get an IPv4 lease, and we don=E2=80= =99t have to deal with the problem of it getting a lease before it gets = an answer from DHCPv6 or RA and then having running connections that = would be killed. --Apple-Mail=_F78374D2-B8A8-4E60-8176-8E19FB7A0795 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 4, 2019, at 12:43 PM, Nick Hilliard <nick@foobar.org> = wrote:
approach is = better than the other way around :-)

Because once the device knows it=E2=80=99s on = an IPv6-only network, it doesn=E2=80=99t have to keep trying to get an = IPv4 lease, and we don=E2=80=99t have to deal with the problem of it = getting a lease before it gets an answer from DHCPv6 or RA and then = having running connections that would be killed.

= --Apple-Mail=_F78374D2-B8A8-4E60-8176-8E19FB7A0795-- From nobody Wed Dec 4 12:49:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBA120895; Wed, 4 Dec 2019 12:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROU1lWA-ka2D; Wed, 4 Dec 2019 12:49:11 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A969D12004C; Wed, 4 Dec 2019 12:49:11 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id v93so295405pjb.6; Wed, 04 Dec 2019 12:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FFmT85JQ9y4Lh33mWWjVNjjuyDOUW/EKtu6Ufa/F+eg=; b=R4AgRxTtQSzavMD9aO9pv2IdRXJMFzh/QS+cxZZbo7/vVpbE18SqathXI7qOqH1VOd 9q2ixR3hoDpbuhqlRB+M8gIUxqrtwwUxRgVFSH9qLg2NvSk1jm+dbFFNC06l9dZrr1od eflAwUNbJLC5ZZpo0onb5LECxL2NakDdRJI+5sHeNi+ZuLX/AcKzmuzHDBNGILfuxLJr azpFQXOwugrJop/Mvfy5Jb5q/fGqHx3OQ6KGcgFma/2qeF+8O3tEpRL4gYK4B9djIRLO SCLIXs3qlSGcaeOt88epQ49BlSJd5dUCpBhgSIZgvUFEi6CYZwalDpZPWYhSghS0lgGu n7Mg== 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=FFmT85JQ9y4Lh33mWWjVNjjuyDOUW/EKtu6Ufa/F+eg=; b=SEXZ+cv69djNwIQm4+f9XCwYRu9PaYg8qCT3ysAAxW1FtsNip9C1FcLJRm86Ba9X+Y W5F4Vv7AqH2qt2uEO2Fb6DxzwnQUkeerXA8pxCCPKcWyAaFCZREVAG4erPzLt/xlEZ6s zho8Ya6W06E98eY/bBAeRrv4VWeVndeUWGxsd476CdN7H06mvftQEOZlDxc1Ifos2wwc FtXyptlCAGwhLkzXnGBj8Ucnba/gdWrGHnihTWK33aVJWm6GUd2lIRxUBrYTqFYA94I4 bA2dSLiQhB0O7AO9NahLhPLs2PxxHy5AqPToZdQ66Lq88mKrKU9m4e7HI43FaBtGLjk1 J2Zg== X-Gm-Message-State: APjAAAV9dZgNG+lgYTl0lW5gvLk44qffxBopAB2Jpwg31P7mLSKZu8+T qHpPaUJKnzFroKRa47VKdsQ= X-Google-Smtp-Source: APXvYqzjOr1Dlt2w6OzfYcD44ZYwSYspZkOhSdZ4s0r3iMPfVIepEIBM4bQPgCsRc0H2dXzWvHx86Q== X-Received: by 2002:a17:902:b403:: with SMTP id x3mr5382931plr.109.1575492550964; Wed, 04 Dec 2019 12:49:10 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::1010? ([2600:8802:5900:13c4::1010]) by smtp.gmail.com with ESMTPSA id z19sm8593438pfn.49.2019.12.04.12.49.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 12:49:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Fred Baker In-Reply-To: Date: Wed, 4 Dec 2019 12:49:08 -0800 Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jen Linkova X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:49:13 -0000 On Dec 4, 2019, at 4:09 AM, Jen Linkova wrote: > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. A general comment - I don't think this is "devices" as much as it is = "applications". I'm thinking here of issues raised in RFC 2993 among = others. I would argue that NAT64 is subject to the same issues as NAT44; there = is a coupling between the network and application layers in that an IP = address is used as an application layer identifier, and a coupling = between addressing domains in the network in that hosted applications = presume that an address they use is meaningful to and means the same to = an application in another domain. RFC 3439 talk about coupling primarily = in terms of time, but couplings such as I describe are also dangerous, = and I would argue that the issues raised in RFC 2993 are direct results = of coupling. So, whenever an address is embedded in application data and = interpreted or used by the peer application, there will be a NAT issue. What would I want to do about it? I would not want to see an ALG (to my = mind, that works against higher layer security such as TLS or IPSec), = but rather see the application use an application layer identifier such = as a DNS name.=20 Of course, my opinion plus some loose change might obtain a cup of = coffee... From nobody Wed Dec 4 12:50:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1FF120895 for ; Wed, 4 Dec 2019 12:50:13 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkRy0aZ25Ssc for ; Wed, 4 Dec 2019 12:50:12 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5327E12004C for ; Wed, 4 Dec 2019 12:50:12 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id w47so1205063qtk.4 for ; Wed, 04 Dec 2019 12:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AVTaRPNdH4H28ThIauzbluDtRdREYlgrvafhqSkzDFM=; b=rbtisdih0aRsU0cnYQPLQd3dZg9knDICuceetJ87Jv1piHTKr/GuV2JUn9oMIH1cdu gBtUerr0CR0+OaMRWVljNuXVBhBRKUoFNSchIV6FiW3ZcAmiZ0e+EYE/5JfEbRbzGyKW 6CvK1Eui9mtRulh6z+7EGTgGsyG8H8acWLS80kJYFB5Vq+e5xrhQEumkNKopUFmQo7g8 +bZqNJLhu+JmPuK10aNW/klcEeHw2ne53uDnUPMQdg86CP3G6Q5fiFmBLEhehw4B3xC4 H0OTGaN74cGTD3R4swl3tU7lu0F2aZ4mrerDy/MI/Xix19MxuaD7K31aTnVRyMgFfjl8 74vQ== 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=AVTaRPNdH4H28ThIauzbluDtRdREYlgrvafhqSkzDFM=; b=MpxcwkRsKLUTleBU7BnAqncgX6qo20NuSqKp7EQLLKtN8r9Rof9qKC5J0V0nePqHX9 wgwHFIAh+AJ8yTmiMboJaTiyO3ADtV3JHrLSCrIxOLp9WtvjBTih+NCtG/HyV0Nvwcv5 iwpMoPgAs4mfufp0512bofeg/GZTwm8jInQTCkNTPgniP3bQeNNAL8txlSpf5vNZYNv2 6UrWExJuP09WgUdNZRHMzEuqq5jgsVedGouTYCAKq1YYFM67nSpHbVWJqqc/dF08HL/r kDTyY8uXQYoUpYXSn4oOsCzyeQ1+GqdJs3hPVTBDb9x23WJpZRKRpey59vFJAfc+ecl9 uNrA== X-Gm-Message-State: APjAAAV1CnUBdC36E3VBeHSUM+lIc3bBkw3rXgRtwxChUPn3VZFKPTfy 3eDFABa+jOg5wi9FWHzeefjigNYenfvG0Lw6RGw= X-Google-Smtp-Source: APXvYqzMeZg1Tbm68LYZlk98ATdlpmowvS2qj6uLhQRhD/rbFYic3HI+OyDtYXQnme3f5NYFSxsHsikDlSb9zU+BU8M= X-Received: by 2002:ac8:1e13:: with SMTP id n19mr4661237qtl.384.1575492611130; Wed, 04 Dec 2019 12:50:11 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-Reply-To: <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> From: Jen Linkova Date: Thu, 5 Dec 2019 07:49:59 +1100 Message-ID: To: Brian E Carpenter Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:50:14 -0000 On Thu, Dec 5, 2019 at 6:53 AM Brian E Carpenter wrote: > > As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoid IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell hosts to prefer IPv6 will also be accused of being an operational nightmare. I hope not and let me explain why I have that hope ;) AFAIR the main issue with using IPv6 to signal to the host 'pls turn of IPv4' was that many IPv4-only networks might not have IPv6 security in place. So an attacker can use IPv6 to a)turn off IPv4 and b) break IPv6 by sending a rogue RA. What this draft proposes is to use DHCPv4 to signal to the host 'pls turn of IPv4' . The same protocol, not IPv6. So there is a shared fate here - it the network allows rogue DHCP servers then IPv4 is doomed anyway. But it's all is working over IPv4, no IPv6 involved. > On 05-Dec-19 07:22, Michael Richardson wrote: > > > > Tommy Pauly wrote: > > > Thanks for posting this draft! I find it to be both a well-written document, and a great solution. > > > > As an author, thank you. > > I think that this document grew quickly from hallway discussion at IETF106. > > > > > As a client OS vendor, I think this would be easy for the client hosts > > > to implement, and we'd likely see a scenario in which pretty quickly, > > > most modern mobile devices and laptops would support this, and we'd end > > > up with using v4 on networks only for more "legacy" devices. > > > > A question that we had was whether or not hosts in a IPv6-mostly network > > should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts. > > > > The DHCPv4 option has a payload value that can be returned with information. > > Right now, it's a boolean: if the option exists the network is ready. > > We have considered two things: > > > > 1) We could put a time at which the host should recheck for v4. This avoids > > making mis-configuration of IPv6-mostly networks permanent. The question > > is not whether such a recheck timeout should exist (it must); but rather > > whether we should allow it to be configured in the option, or if we can > > just suggest some implementation local value. > > > > 2) Whether or not IPv4-LL (169.254.0.0) addresses should be configured or not. > > We could make this an option in the payload here as well. > > > > We wind up with four classes of v4-hosts: > > > > 1) IPv4-only legacy hosts which do not speak IPv6 at all. > > (The old printer in the corner, a whole plethora of stupid Web-Connected IoT devices) > > Some might not even have IPv4-LL addresses though! > > > > 2) Dual-Stack hosts do not understand this option. > > They have IPv4-LL and IPv6-LL addresses as well as IPv6 GUAs and ULAs, so > > they can talk to any host on the network. > > > > 3) Dual-Stack hosts which have an operational need for IPv4 that is not > > satisfied by NAT64, and which therefore either do not include this option, > > or for which the network is aware of their need, and does not answer with > > the option set. > > > > 4) Dual-Stack hosts which turn off their IPv4. > > Do they keep IPv4-LL so that they can talk to (1)? > > > > [5) IPv6-only capable hosts which never speak IPv4] > > > > -- > > ] Never tell me the odds! | ipv6 mesh networks [ > > ] Michael Richardson, Sandelman Software Works | IoT architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 13:40:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D712004C; Wed, 4 Dec 2019 13:40:12 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP3iuZkzdlQQ; Wed, 4 Dec 2019 13:40:11 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4598B120033; Wed, 4 Dec 2019 13:40:11 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id d124so1435753qke.6; Wed, 04 Dec 2019 13:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IY+8xJ+TPb41+qwCJgVlEg37ypZjQ354ynM9eXaVuuw=; b=diqsCcux3gOUuXZPaaIOBqKuQbxMmUAKZhtr6lgDM53sAMhRE6674fCw5yHpNE4WT5 WknLe41HvB+s+eq16fFYpalJLNb7Wykhj39QNncsrAme7QJeLXiEiJuH6CSQwMEY8wr7 d99103D1h0FojfmUVu/F1Y4K8ZIoE3J0ervf0DCSTZa2Tp+z0jEz94EzF/SgrGhgUFnR F9sX+ST/9i/JJs3LUSbuw2tTNXcLSmAWRJNSep8p9mPFs1EYbO+ARMEaZdvpYZAkrA2m 35I6pAr44plByKFYS79wA6vR86EYJsN0OX6SN6C4P3T72xvf6INikfz18FG+TeAmDsmI lQ3A== 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=IY+8xJ+TPb41+qwCJgVlEg37ypZjQ354ynM9eXaVuuw=; b=qGyjlTWZhCTLdg/7cJeKAtJmBrZyrTzxwTanYRkkWSLPYuYrNXGU2QFVmpCOemmwyk xnEYhaxZO6vuaxYrcdw5PhXneL0FUl1TCoVn9xAb3Majq+jZpqvyFuJt9PCVE9aWe7lA sM6B38AujjuhcyviqVifMIK9Jo2avu+ROFrPuacy3RoE1nyGXI99NnwK9ci5lFZTHi7t Cx3gX82GmvG/lY1tqC9A+0WJopUAWuoIdKwmjFYIJG3/6IdZrbDie0slaVYZou3MCKN+ BkOSMcaEtrbgf38KTiSUigLndViXJtYu9FbHRq89zfIHXKGOwPGiFkG9pcnJcJKdzn5F dIDw== X-Gm-Message-State: APjAAAUKnPjE5luyxIQ28rXy6UEhoWIGoyQkGebP/4/xk/FIsTb698YT X8Z1pGrdh/jwjuPNv8eH66Wk4D1bvexO2FeXy/U+Qw== X-Google-Smtp-Source: APXvYqxy7BkXBkxLIxfbr6Dqq3BmRWmvZVBhKTW5Ky/kL+JL4Mv2siCQzjHbM/NA4Br1Lij9gOYYY47V2RXYxlmiIac= X-Received: by 2002:a37:9fce:: with SMTP id i197mr5050786qke.466.1575495610062; Wed, 04 Dec 2019 13:40:10 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> In-Reply-To: <8736e0gqu2.fsf@miraculix.mork.no> From: Jen Linkova Date: Thu, 5 Dec 2019 08:39:58 +1100 Message-ID: To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 21:40:13 -0000 On Thu, Dec 5, 2019 at 12:31 AM Bj=C3=B8rn Mork wrote: > Why can't the client just release the IPv4 address when it finds it has > IPv6 connectivity? This would also avoid the problems you introduce > when the network falsely claims IPv6 support. One reason has been mentioned by Lorenzo: releasing an IPv4 address is disruptive to applications (point taken, we'll update the draft text to make it clear). Another reason is that it would bring back all objections we heard about IPv6-only RA flag: 'an attacker sends an IPv6 packet - and IPv4-only network might not have IPv6 security in place - and breaks IPv4'. What we are proposing is that DHCP server must be explicitly configured as 'this network/pool is IPv4-as-a-service' so to do any harm the attacker needs to deploy a rogue DHCP - in which case your IPv4 is trouble anyway. --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 13:51:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABA1200A3; Wed, 4 Dec 2019 13:51:50 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9DS8-SQwWIo; Wed, 4 Dec 2019 13:51:49 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AF6120033; Wed, 4 Dec 2019 13:51:48 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id b5so1323276qtt.11; Wed, 04 Dec 2019 13:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2pWCH+JRPB3KyW00FRIWKys2BGVEPKiBfZ2pRdb20PE=; b=aJr9Ls4edS4Ga3UlJjMVjBw1O0HqTm4uSaKKb/5JFngFQC9JWns4iVnf8ygMiw9jLK NmgzEMdSWM+h3fN2EL2fiDKZIT9+SLn9wCFLG8yhBICZcbs6CFX+8D59nvjPQy2YsLm7 YFJ0mteqeP4I6+kLfzoR/Gcdii/dxlexQAkxZJMeWi00E5PJw1ujRrHuMuwE0uEQLZ/B zB/D5Mp8ppipDni33Eq61vltXPb2qt1VqTSfikpWx4ddcrv68JVqwc3YGsiuZOticdyy 8MU74wo0fEMHMqZ30jpnu+wkLysAnU7USOKMfsYXjZ7ztMiyNSIpmHYI55wvWwLHuBH0 ow7g== 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=2pWCH+JRPB3KyW00FRIWKys2BGVEPKiBfZ2pRdb20PE=; b=TeSFnj2rpetB/GynaMPXC8ZHyd5AaTkBMnwhf9yoamKwP/PhSRR6P5128n20jnK5qv pLnJhIqIBm3JCnTclSVB5TNDUQnIDGVGW/PPJwNuHhnt2+SqFKjPe5w3dK7LpPKN8t+9 9qltW+v8d5J28Td4lnLnqWIebbpDm7NOLzEHZ8UZzOAfVt+jWx3apVZJYBJes2iG+i7w q/QJWg/xMXkDa26YJthkwopgL0eS0l/GEQzIzfZDyNbkCIpp86//9Yaxvw2wsnaADm9D d8ZcYbdKXJgJAt6WN4siQFmBkGvx/+VFkRdWpHDcUghYapzJlvqE2khKBLeQNHJA9mOt en5g== X-Gm-Message-State: APjAAAVofop6306BD+VSUCN+g+eSJpGTUBK2VfoRK3/v0TTyWK7Z2yZR c/Tyf6ExW4JCRKZ8Tm/HA2Wxn162l3jvtidONic= X-Google-Smtp-Source: APXvYqwKtBzrRvWyHJ375ODQJ6uggpO+SSAp0YPgdCK0APQZx86zQYBu8bYi+/eKF8dl1YG9pE51GoF1RALBXmH7oQM= X-Received: by 2002:ac8:5313:: with SMTP id t19mr4886610qtn.118.1575496307554; Wed, 04 Dec 2019 13:51:47 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Jen Linkova Date: Thu, 5 Dec 2019 08:51:35 +1100 Message-ID: To: Mohamed Boucadair Cc: =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 21:51:51 -0000 On Thu, Dec 5, 2019 at 12:56 AM wrote: > Blindly releasing the IPv4 address when an IPv6 connectivity is available= is problematic because the host does not know if a NAT64 function is avail= able for a given network attachment. A host that discovers the presence of = NAT64 (because a pref64 was discovered) can safely release any assigned IPv= 4 address. No additional signal is needed in such case. it would be no difference from what https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag was proposing. And as many of us know, that draft was not able to reach consensus, the main objection being 'we can not allow an IPv6 packet to turn off IPv4'. What dhc-v6only draft does is allowing the DHCPv4 server to be configured in such way that hosts can selectively turn off IPv4. No IPv6 traffic involved, everything operates over IPv4. > Jen, do you have a case where you want to deploy IPv6-only host without a= nnouncing pref64 to that host? I *am* deploying them right now, because pref64 draft is with IESG right now and many of my routers are not able to send out PREF64 RA option yet. I agree that in theory pref64 presence is a very good implicit signal for 'you don't really need IPv4'. However when a host connects to a network it does not know if pref64 is available when it starts DHCPv4 process. So to use RAs as a signal you need to either delay DHCPv4 (=3D=3D penalize v4-only and dual-stack networks) or do all those undesirable RELEASE tricks later. I believe this is discussed in the Introduction and the Section 2 of the draft but I'll look into how to clarify the text. > > -----Message d'origine----- > > De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Bj=C3=B8rn Mor= k > > Envoy=C3=A9 : mercredi 4 d=C3=A9cembre 2019 14:31 > > =C3=80 : Jen Linkova > > Cc : dhcwg@ietf.org; V6 Ops List; draft-link-dhc-v6only@ietf.org > > Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option > > > > Jen Linkova writes: > > > > > Hello, > > > > > > One of the biggest issue in deploying IPv6-only LANs is how to do it > > > incrementally, when some hosts work just fine in NAT64 environment > > > while some legacy devices still need IPv4. Doubling the number of > > > network segments (having an IPv6-only and dual-stack segments of each > > > type) is an operational nightmare. So it would be just awesome if all > > > devices can co-exist in the same network segment and hosts capable of > > > operating in IPv6-only environment do not consume IPv4 addresses. > > > So here is the draft proposing a new DHCPv4 option to help saving IPv= 4 > > > addresses and deploying IPv4-as-a-service: > > > > > > Name: draft-link-dhc-v6only > > > Revision: 00 > > > Title: IPv6-Only-Preferred Option for DHCP > > > Document date: 2019-12-04 > > > Group: Individual Submission > > > Pages: 9 > > > URL: > > > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6onl= y/ > > > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc- > > v6only > > > > > > > "While IPv6-only capable devices might use a > > heuristic approach to learning if the network provdes IPv6-only > > functionality and stop using IPv4 if it does, it might be practicall= y > > undesirable. One important reason is that when a host connects to a > > network, it does not know if the network is IPv4-only, dual-stack or > > IPv6-only. To ensure that the connectivity over whatever protocol i= s > > present becomes available as soon as possible the host usually start= s > > configuring both IPv4 and IPv6 immidiately. If hosts were to delay > > requesting IPv4 until IPv6 reachability is confirmed, that would > > would penalize IPv4-only and dual-stack networks, which does not see= m > > practical. " > > > > > > Why can't the client just release the IPv4 address when it finds it has > > IPv6 connectivity? This would also avoid the problems you introduce > > when the network falsely claims IPv6 support. > > > > > > > > Bj=C3=B8rn > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 13:54:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034F31200A3; Wed, 4 Dec 2019 13:54:34 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBzWJxQc4hFD; Wed, 4 Dec 2019 13:54:32 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9643F120033; Wed, 4 Dec 2019 13:54:32 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id d124so1471713qke.6; Wed, 04 Dec 2019 13:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VcTT1sbbXICxl0QnohpHw4HfdnMbZEotobKcX3/M0fY=; b=aptyy4BGzPD4FrblZ/fFPQrp+dWkQW9KWSInsRyj/vFjDDYdH5FJWHAqeuWj6bGIod a4ekvqPxbqq0EdP/2bmtMZbvglRWwodou+lMjHZm7y9SLWP0EkSe4ze3h8psWk/MPEzG UIyE2r2npK68kntcqEd3Y1f1PQ5WLFUHfd/zFZ6rEooTeCzBtaWXZ7LGOq/iUYlpukhG oSGJrhLMR4Q0OI/t1g/8yBcustZ7zhoEIvFkatsmevdBgcgIKHWpZ1/ozy8d3y/j9U1p tm/Gyon2Kc2Jk+NDXbfrbytgKNDw/0zaUfVYPZ4NQVXib2IsPazoNqXz/7dM5jTHQv2B jGhQ== 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=VcTT1sbbXICxl0QnohpHw4HfdnMbZEotobKcX3/M0fY=; b=UrLXdL6JMrp4ZzpuGAJYPY11TXNiLdtbkfX8VMjpaklAa2N4Pf4py7odKwXz31gydl dLdJP9NimLf5opqkOM9tn1rC/w2pyymq75A7ZR7Mz60RX8I9srWkbh9Lg0JP/6TyCAUX 0YV0cVZVgSCZgk8jWIGmd9SEAfkripMvZi5rFvNH/LSlp0xOtYevNGVpmDJoCHlbMPqu 0ow1f37a/+rvNBpgq52PRTBAuFU1LsRf/s0dGvlEaEVO6knz2cs7imNQ+icvlRAmEvXE fy4FF6GZ6T3ykIHhtruW5Eiw4qCqrPccrO6bEP++C5fc0UOpbJXCHxR4yexnpDoV59lz 1QEQ== X-Gm-Message-State: APjAAAVDOBm3Dlg6xiMN+1i77AoASMZI7V+bOt/hnDwTNKBHrSELOsyx xNLDp7c22kKBVfy/sO2u7yz8Q5Wepkbn6CDd1XGFw9Z3 X-Google-Smtp-Source: APXvYqysjf7xONtPmxogh5A0IYgwZbSv/278jHt3vwkOEnLwmBvTtWkG355YhE/2CUKcxbygTrxJY8mhAmTxIRn6cCg= X-Received: by 2002:a37:9fce:: with SMTP id i197mr5092316qke.466.1575496471322; Wed, 04 Dec 2019 13:54:31 -0800 (PST) MIME-Version: 1.0 References: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> In-Reply-To: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> From: Jen Linkova Date: Thu, 5 Dec 2019 08:54:19 +1100 Message-ID: To: Ted Lemon Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 21:54:34 -0000 On Thu, Dec 5, 2019 at 4:29 AM Ted Lemon wrote: > > This is good in principle. The client behavior section should require the= client to send a parameter request list and to specify the option code of = the new option in the list along with any other options it expects to get. Thanks Ted! A clarifying question: the draft currently say (https://tools.ietf.org/html/draft-link-dhc-v6only-00#section-3.2) "IPv6-only capable clients SHOULD include the IPv6-only Preferred option in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST messages." Do you think smth else should be required here? > > On Dec 4, 2019, at 04:09, Jen Linkova wrote: > > > > =EF=BB=BFHello, > > > > One of the biggest issue in deploying IPv6-only LANs is how to do it > > incrementally, when some hosts work just fine in NAT64 environment > > while some legacy devices still need IPv4. Doubling the number of > > network segments (having an IPv6-only and dual-stack segments of each > > type) is an operational nightmare. So it would be just awesome if all > > devices can co-exist in the same network segment and hosts capable of > > operating in IPv6-only environment do not consume IPv4 addresses. > > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > > addresses and deploying IPv4-as-a-service: > > > > Name: draft-link-dhc-v6only > > Revision: 00 > > Title: IPv6-Only-Preferred Option for DHCP > > Document date: 2019-12-04 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6= only > > > > > > Abstract: > > This document specifies a DHCP option to indicate that a host > > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > > address if the network provides IPv6 access. > > > > Any comments/suggestions/reviews are highly appreciated! > > > > Adding v6ops@ to Cc: as the problem is related to operating IPv6-only n= etworks. > > > > Thank you! > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 14:20:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A94120046 for ; Wed, 4 Dec 2019 14:20:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 N_hnF4ZFSpbi for ; Wed, 4 Dec 2019 14:20:07 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF4712002F for ; Wed, 4 Dec 2019 14:20:07 -0800 (PST) Received: from [192.168.4.77] (unknown [190.179.35.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 75C558521E; Wed, 4 Dec 2019 23:20:03 +0100 (CET) To: Jen Linkova , Brian E Carpenter Cc: V6 Ops List References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> From: Fernando Gont Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <7b646344-d0b7-ee6e-d732-4e10898b61e3@si6networks.com> Date: Wed, 4 Dec 2019 19:19:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 22:20:10 -0000 On 4/12/19 17:49, Jen Linkova wrote: > On Thu, Dec 5, 2019 at 6:53 AM Brian E Carpenter > wrote: >> >> As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoid IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell hosts to prefer IPv6 will also be accused of being an operational nightmare. > > I hope not and let me explain why I have that hope ;) > AFAIR the main issue with using IPv6 to signal to the host 'pls turn > of IPv4' was that many IPv4-only networks might not have IPv6 security > in place. So an attacker can use IPv6 to a)turn off IPv4 and b) break > IPv6 by sending a rogue RA. > > What this draft proposes is to use DHCPv4 to signal to the host 'pls > turn of IPv4' . The same protocol, not IPv6. So there is a shared fate > here - it the network allows rogue DHCP servers then IPv4 is doomed > anyway. But it's all is working over IPv4, no IPv6 involved. Disclaimer: I haven't red the document. But based on your description, I would suggest that the subject line is changed. And that if there's similar wording in the document, that's changed, too. An DHCPv4 option to turn off IPv4 is acceptable (the two protocols are *npt* being entangled). Whereas the subject line makes one thing that you are using IPv4 to convey IPv6 signals -- where in fact you seem to be using IPv4 to signal information about IPv4. I'd bet that simple change in wording will save you a lot of time ;-) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 4 15:07:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0596120090; Wed, 4 Dec 2019 15:07:26 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP0S7sMQe5Fs; Wed, 4 Dec 2019 15:07:26 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA29412003E; Wed, 4 Dec 2019 15:07:25 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id b18so557522qvo.8; Wed, 04 Dec 2019 15:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U/yCiNBem8dtiL9k5MqxE5g9mVpL1Wyiq9gRXWQYoTg=; b=Cq3DzLgp3RGYGbBfQKTYcWP1Ygsv389ScqNSAFbCOzeq987M8DzyA3FNWWq/BU2PME wlsw/p9ttsVRGHLCV9X92R9XNb5thuO6HoJDrvOLbLuWFFMH+9DACSsBJz5XMYp35Jzk 4F60B4VvjJcs7llcpotd6Z3EkwJisGXsVaaDbmdkNS/NnPzt9N5h1d+YQNMhMvPoLQX/ qu/mCZOSGcIN23mbEsvW4J3X2p+PNGqGDd/tumHMfZ11N8W02dnItX9IXH8ViWXxR44W akpn6LyrNXo6T8e3h/GKVfITceJWh3CU9+uMC2CcQTD+qt9fob0UdFz5kvFTkE0pwXmy 0ukQ== 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=U/yCiNBem8dtiL9k5MqxE5g9mVpL1Wyiq9gRXWQYoTg=; b=WvAgaFMAXH4J/GUYNX4vImbzkeIYVba1RcH50lkffmtd+rSSJ9uPKoLI062mQ/xFSn /nf1SWK3MhpzLhMlKZklTNUOSHi3Los/mpxDI4zFUP35KlBO4V2lA3uBDtlV09G/SOsB R/snNQw2cPH64iWySKhvJioIbOKeUTlsNSgZCsohxEbqB0EAxk5Tt9Tu/FYy3X7KQ2hW 0FFuJObJVWhX/3tbH2l2SV7rKsoONUJnakO2BEnwWx2wwxATDzQIg7rCe06L7trFq0k1 CoG3olECa1Osh1h+1FFtH+o6NCeAybXB7qPq6Kg9GjU4UpsKh2fvlGpkutpYtEoO6G5w Iltg== X-Gm-Message-State: APjAAAU1bk/RI0XTWAaIfC6oCB5/YTKVV0NXuwkAIhY0dCmJIuQBB250 N1+yQa9ay93p8HClriA6hBUPg4n9IXRuQjSrG+BF2g== X-Google-Smtp-Source: APXvYqzB4uu/ea7gURWP6qKb0Q67oEK68a/M/PBlMw7jEfOG4WfPAhLsbQPUNfPlTs+YlJKrxZxy56kEQtq0pw6KZqQ= X-Received: by 2002:a0c:ad35:: with SMTP id u50mr5082088qvc.158.1575500844700; Wed, 04 Dec 2019 15:07:24 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: <28594.1575483729@localhost> From: Jen Linkova Date: Thu, 5 Dec 2019 10:07:13 +1100 Message-ID: To: Michael Richardson Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 23:07:27 -0000 On Thu, Dec 5, 2019 at 5:22 AM Michael Richardson wrote: > A question that we had was whether or not hosts in a IPv6-mostly network > should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts. Actually the more I think about it the more I believe the host should be doing whatever they are doing w/o DHCPv4 presence. Android does not configure IPv4 link-locals, MacOS does. Making the same OS behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server responded with IPv6-only Preferred option") might be undesirable. As an operator I'd expect that IPv6-only capable host would behave the same way on a dedicated IPv6-only segment and on IPv6-mostly segment. -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 15:11:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6E120090 for ; Wed, 4 Dec 2019 15:11:10 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8g8ZnxIS3ga for ; Wed, 4 Dec 2019 15:11:10 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A83E12003E for ; Wed, 4 Dec 2019 15:11:10 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id i3so562177qvv.7 for ; Wed, 04 Dec 2019 15:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+m23QxP6PFEuv7fUMK3rJgKG7Yjjk1VgDMWa7nWnDks=; b=PCrknvYKH2CY5rcDb3JTE+5Cuiio0/XTQj+MzyA0eL5jHCEtZ7xR2InpUbGCzrQuZr UPdYO3o1DGD95b/rtbKUkB2Dwj2KNWw7ADQYM8iI9JwoABklPyogBZMk9A1+g1dp8itQ jqLlOM81hULo8ZMsgbtEJ2EvGYMurGQukxB0w2C7sN4uSJ4qC/AYoVx2Y7vhN7wOhzHT opspFq2yWGqcKfCEGvuDukq0Y9fZTO+ODKKQ1rhXQRnqWtRz+kIkiBRZnVmNLYAhH1ud n+4rwC/6CwEScv0GQ/ltRsZpiUNWKvweAQy3aP8xpTPXIOhskHnDQtsETMA5rydc7WEi qGyw== 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=+m23QxP6PFEuv7fUMK3rJgKG7Yjjk1VgDMWa7nWnDks=; b=MEgKNV1vL6krCzycjsBhlIKHvxIGBrZAGk1YsDU9TQ9CFpe9B7+tAN3lTi7tbQJz/l FcKl0tlVUuTz68JbiQ261xUoPhC2lFxmga5KOVxoe4Ze3Z2rNKPFi5jE3h+ZQwB8h4NA HB1pXUkh4XkGfn+VIBi0pUCScRmXTc+WSqhHOKGDoYYX3gqXRbbNFx/jhRxRefnACxcF 4h5brajeQ2pOESGkKhRx0bu4Ue0sfQU5kraci5xwRgEYLkBudFUAevNT+bI8W4c9XK3D KpmQsOGtqT1fVKq+a6iRRfBUmJVGuLXqfrcUwh3dnMBwKq+hqdEwmI7LmZimFR72fHFE KsfQ== X-Gm-Message-State: APjAAAWYQh/GH25TNEOkEnYFTQ8tlvD8d7FJIQL4TtJJxJvojfPzmV4d RmIOUG8lN97cw3MmF2YsdFVDuHMkSoEGjqH5nihY3w== X-Google-Smtp-Source: APXvYqymWksT243whYc5tHTew3VEhrugdSP5b8JzA3LipSP4VeOMKHwYDTfFQmL7zyJFq17iHB74/0ygjtM5bcT/nOA= X-Received: by 2002:ad4:496f:: with SMTP id p15mr4884331qvy.191.1575501069041; Wed, 04 Dec 2019 15:11:09 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> From: Jen Linkova Date: Thu, 5 Dec 2019 10:10:57 +1100 Message-ID: To: Nick Hilliard Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 23:11:11 -0000 On Thu, Dec 5, 2019 at 7:43 AM Nick Hilliard wrote: > I haven't read the draft yet - and won't get to it for a couple of days > - but am also curious about why this approach is better than the other > way around :-) I hope that after you read the draft (you only need read pages 2-7 actually) your curiosity is going to be satisfied ;) Otherwise I'll do my best to answer any questions you might have on that topic! -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 15:27:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00512003E; Wed, 4 Dec 2019 15:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X91ND-emzqMP; Wed, 4 Dec 2019 15:26:57 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B2C12002F; Wed, 4 Dec 2019 15:26:57 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id d124so1677076qke.6; Wed, 04 Dec 2019 15:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ylM1iSSKb4oWLjyno2cvBZPqPlRmJUf5VXnN1+KPDIU=; b=D7u3LktprXI2Qbrbe5qQ8SoDqP7YMzHT3i3FLWlxc9BVmaUc8I7V5lOlofqdtJSVqV 3ZQ45KJEWuqM1g4mkKosdQpb26HvA02kAyIsuwG/4guJ7FGSfBdu0897zv5gdE5xZvdd D7NaNGkNzPxpMNf8Ob59fM1jz40uupIpi2+Y+iUv2RJoPHHx0qC6QhLdARs7ZRo+YrtI z2xDN+WMLi6hdcldxjil0oGOaFzRA7PuPdf1JztP22KUpjVXyKL6i4aYD2TKANC6L1IX Q5kLfHmoZJ8wWiAleJfoEbcy15yk5/01XjaR4zkdBEtowGAHr81WG8vPT11z1xfmx8Ca QjJQ== 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=ylM1iSSKb4oWLjyno2cvBZPqPlRmJUf5VXnN1+KPDIU=; b=R265WXTEkMJJ6qtMdDlYZ3PnLQ5SLlZaG110BxkXUX8oo2nO4lnSbwb/8/Gx0k4J4a BdI2PsUsco2cOF1lu3U8fva+l41DteCrkFOQwK62xURNc+00lphK9FVoo16q36smRgT7 eiPxkwFldrfjgXU0CfiIZfPxlKDsrlMtGBEv+N4N/KsWKSci1wxn3/B3WqB4h6tT2E4P ec7deYK0wca2IyHrjQ/Q3sABlN6h7lSEtMu/xPtudGc1xJU0LwSWzGQa26AfoX4B2+pw FyGi29Rkn/XLvI9hwbYHB+y+vUT8aiVmGQNyDv3ChMizb2tWfo8qSczMcUpXiQNVt/XM HBSw== X-Gm-Message-State: APjAAAWaelep3YjiniokkxY0xJxnKSLGQa2AQbijYsOc0zY1CQKosJHv cnrXyRakOOFfse9Hav5lPT2VSZ2l0IHE7m3g57s= X-Google-Smtp-Source: APXvYqzRqEzfj1WESbkCK8/mIZPr7mW9DvuUgrA11oiExHjHArmPFFhL+wL3Lhea23Jbboi9zheEMxTTFsuxz6JaZyc= X-Received: by 2002:a37:4841:: with SMTP id v62mr5384917qka.444.1575502015568; Wed, 04 Dec 2019 15:26:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 10:26:44 +1100 Message-ID: To: Fred Baker Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 23:26:58 -0000 On Thu, Dec 5, 2019 at 7:49 AM Fred Baker wrote: > > One of the biggest issue in deploying IPv6-only LANs is how to do it > > incrementally, when some hosts work just fine in NAT64 environment > > while some legacy devices still need IPv4. > > A general comment - I don't think this is "devices" as much as it is "app= lications". I'm thinking here of issues raised in RFC 2993 among others. You are right, it's applications getting broken w/o IPv4 indeed. The text is saying 'devices' just for the sake of brevity: as a network engineer I see *devices* connecting to the network, and IPv4 addresses being assigned to the devices. A device just a box with a number of applications (+ an OS) running inside. However there are cases when an application needs an IPv4 address to operate while the whole device does not. Think of a device with 464XLAT enabled (e.g. an Android phone). The same application might work perfectly fine on a mobile phone connected to an IPV6-only WiFi but gets broken if I run it on my macbook connected to the same network. Would it be better if the sentence you quoted would be saying 'while some legacy devices still need IPv4 addresses as their OSes and/or applications depend on IPv4'? > I would argue that NAT64 is subject to the same issues as NAT44; there is= a coupling between the network and application layers in that an IP addres= s is used as an application layer identifier, and a coupling between addres= sing domains in the network in that hosted applications presume that an add= ress they use is meaningful to and means the same to an application in anot= her domain. RFC 3439 talk about coupling primarily in terms of time, but co= uplings such as I describe are also dangerous, and I would argue that the i= ssues raised in RFC 2993 are direct results of coupling. So, whenever an ad= dress is embedded in application data and interpreted or used by the peer a= pplication, there will be a NAT issue. > > What would I want to do about it? I would not want to see an ALG (to my m= ind, that works against higher layer security such as TLS or IPSec), but ra= ther see the application use an application layer identifier such as a DNS = name. NAT64 is not perfect and is not a silver bullet but I do not think we have any better tool right now. At least NAT64 is used for iPv4-only destinations only so damage is contained (and the footprint will be reducing over time, I hope). --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 15:57:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6872B12004D for ; Wed, 4 Dec 2019 15:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 sfpZLMTv0yMW for ; Wed, 4 Dec 2019 15:57:32 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D49012002F for ; Wed, 4 Dec 2019 15:57:32 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id j13so1681062ioe.0 for ; Wed, 04 Dec 2019 15:57:32 -0800 (PST) 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=/yEbqBuhc7VHdPgsut9MqT3uP6N04RwPbRCymkbTyhU=; b=ptWpZA0Vs1cgbyf8rwchMk4nMjP08cOFnU2rC83QDG2Z+ryAZOckcyKJWKaIpTOVAY E7u0+QhD6AER3QIAtrGferUaf4A4Hl2OpFo1PDWsnV740ppsq749PKLmgpnKOByFg4K4 +qZ2n+mWHi9zlxYG+hyyVyhE8X/ZUVvCILtDT/gVs+05qNpqe2MwSopQQZxjNRlnaKwd Z6vPKlZKL1N7NfBmt6gRdUR7M1OQIA2r7CoEJ95zK5fA9gyXt/4ILd//bYYyiDHoUmvq lZhp6/sQHO0byXDFwy/Ib1e825mvNXmRb+ixjYiF+G4ekdw+UFKEtSCkYWk1CDunaObZ dk9A== 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=/yEbqBuhc7VHdPgsut9MqT3uP6N04RwPbRCymkbTyhU=; b=cPwtgpuUyE0IOem0bEVNpIp5bszgkMuEr45Eo9nZZvK7L0us9u/0aJ3DcdH25zMfyC xnNHWGPZfLD6ZbAArR9tK2qRcNrwANj4zoVneg3NdHbuDn/mfxVo5T0N8m6EYm3S0LfR FwO5y4e4E4JU7g2P7deoTUZ2WRLxYITzj1xry2C2zeI5zE6WmQyKHEeBcm5sTKjd5G+V lWQRRu774Myu3fOZTbD7UdfrF1+RTIV69jaSgCEJH1/L/OhVRNpKGj03vtznhksdthOk n/jLhMfy2LlCU2t6OMIP0wuMhzm+xMDdVsIk6Hm6PALrB9RlKLL3LHc0kEww/exL1Atz ji3Q== X-Gm-Message-State: APjAAAW5eZLVlJ0laoX7CF4Wx+GJRql4ypkqIenbjI5CSYwmJT84h4he Kj8aVQ2SRMDdlkAgasmQ+d2fksrTHHCBiwiHG6on3w== X-Google-Smtp-Source: APXvYqw1Lk03nCcQlxoVDk1+6d3LXziHnXzFJqR2X3fPbrnc36wYvbPsYvvHb7UtKME8/H1KkdiaM4wRv7lT3OfW/gQ= X-Received: by 2002:a6b:ee17:: with SMTP id i23mr4491321ioh.0.1575503851402; Wed, 04 Dec 2019 15:57:31 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 08:57:19 +0900 Message-ID: To: Nick Hilliard Cc: Brian E Carpenter , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000068481d0598e993b1" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 23:57:34 -0000 --00000000000068481d0598e993b1 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 5:43 AM Nick Hilliard wrote: > > As an ex-author of an ex-draft that suggested using IPv6 to tell > > hosts to avoid IPv4, I'm curious to know whether a draft that > > suggests using IPv4 to tell hosts to prefer IPv6 will also be accused > > of being an operational nightmare. > > I haven't read the draft yet - and won't get to it for a couple of days > - but am also curious about why this approach is better than the other > way around :-) > Here are a couple of reasons why we believe this proposal will fare better than the IPv6-only flag: 1. It has a clear goal and clear semantics. There was little consensus on the meaning of the IPv6-only flag. Did it mean that there was no IPv4 on the link? That the network should not provide IPv4 addresses? Or that hosts should never send packets with IPv4 ethertypes? If the latter, why not drop the packets in the infrastructure? But then, what about link-local? And so on. In contrast, this option's goal is very clear (conserve IPv4 addresses) and its meaning is very clear: here's an IPv4 address if you want it, but please don't use it if you don't need it. 2. It is using a protocol that already configures IPv4 to configure IPv4. The IPv6-only flag was trying to affect IPv4 using an IPv6 protocol, and that allows attackers to mount attacks on existing networks that have not deployed IPv6 and thus have no IPv6 security measures in place. --00000000000068481d0598e993b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 5:43 AM Nick Hilli= ard <nick@foobar.org> wrote:
> As an ex-author of an ex-draft that suggested using IPv6 to= tell
> hosts to avoid IPv4, I'm curious to know whether a draft that
> suggests using IPv4 to tell hosts to prefer IPv6 will also be accused<= br> > of being an operational nightmare.

I haven't read the draft yet - and won't get to it for a couple of = days
- but am also curious about why this approach is better than the other
way around :-)

Here are a couple of rea= sons why we believe this proposal will fare better than the IPv6-only flag:=
  1. It has a clear goal and clear semantics.=C2=A0 There was= little consensus on the meaning of the IPv6-only flag. Did it mean that th= ere was no IPv4 on the link? That the network should not provide IPv4 addre= sses? Or that hosts should never send packets with IPv4 ethertypes? If the = latter, why not drop the packets in the infrastructure? But then, what abou= t=C2=A0link-local? And so on. In contrast, this option's goal is very c= lear (conserve IPv4 addresses) and its meaning is very clear: here's an= IPv4 address if you want it, but please don't use it if you don't = need it.
  2. It is using a protocol that already configures IPv4 to con= figure IPv4. The IPv6-only flag was trying to affect IPv4 using an IPv6 pro= tocol, and that allows attackers to mount attacks on existing networks that= have not deployed IPv6 and thus have no IPv6 security measures in place.
--00000000000068481d0598e993b1-- From nobody Wed Dec 4 16:26:33 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6927B12004C; Wed, 4 Dec 2019 16:26:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjjCeybECM2t; Wed, 4 Dec 2019 16:26:26 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73B412002F; Wed, 4 Dec 2019 16:26:25 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id v23so1833572qkg.2; Wed, 04 Dec 2019 16:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S8bVSEGBopxFiO6OKdHrplV117IxcuV4hHFvnD4usRI=; b=gD5WaYjDq63yKka8tiS0t/iC3Cf/9go4iRLz2mwvFfQCPDXfZ/IOyWiZzo2xEM5Xdg 8pXG21QzkEf0o4+CR9VWCmapjGhO3vk02ETLu8F/AzoaGC8fThz/+kV4m7gF3Y2fTTbt rCw4Iqo1Jb7GFbGS6j8CXdIeHCyxdtYeICBXxB8ZgZ3gMfMCSA9W/1fKxOAZKc17HLDg nV+u9yLu7o/qMRFlXbaZYiQfK2+CxAVvozl8/Zy6lcbmUseH0+rohBwfkma5vQxmYohP JnOAXWl4QHKd/y73BcxUQ9wZ38QC7jqsKOkoJ0QknSrVIVuINirpXaKvucdgrn7iaDjF Ha2g== 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=S8bVSEGBopxFiO6OKdHrplV117IxcuV4hHFvnD4usRI=; b=DpOf8BQfzZ2dvKXVkLdlgeERl3TK9nEcTfuRWv0/FTxfKlMSeUFUSnYaNJrSzar7oe npTElIzBnN/7jwQwZx59JUEjXh6XBqC3Sn/jE5nOuNOFQPUpSFaAbxpbkQVe0IQoblBj OH/sErJBReQfjt6uygZZPz+fh5nul1zohxWp5ubecoP8mgOffYP/RoK6FdMF69A2v/RN fOn0lHhotLpHITevB5exxu/0JCHfKoxmVbfm93U54EQ0rru2nxKJzms/po//DWrvHemE 4XTGmIVzVDIXJv9Le7tQIjOJGgCmw+IQcncCBBZylf7IVClMfauuyCXO25Y2yIkQQ37P fInA== X-Gm-Message-State: APjAAAWKbLFFzlJSgexbcGal99xvft6Gp/dQsqCO3REsXWhJnU+ZbEjr 8xE246Oeh5IZu0RfKJdbrpj5VTI/Q9fQQi6yQlU= X-Google-Smtp-Source: APXvYqyP1dOSgrNU4y6SKr4Ox2XgydfqVP5QJowzAGqtyZyH4d61bmVM1pUuhHBj4BMjJ9oxmiuFkAJ2cMm6AFPnW/I= X-Received: by 2002:a05:620a:10b8:: with SMTP id h24mr5917757qkk.332.1575505584593; Wed, 04 Dec 2019 16:26:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 11:26:12 +1100 Message-ID: To: "Bernie Volz (volz)" Cc: "dhcwg@ietf.org" , "draft-link-dhc-v6only@ietf.org" , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 00:26:27 -0000 On Thu, Dec 5, 2019 at 7:21 AM Bernie Volz (volz) wrote: > I think there is a typo in Section 2 (middle paragraph): > > Another benefit of using DHCPv4 for signalling is that IPv4 will be > disabled only if both the client and the server indicate IPv6-only > capability. It allows IPv6-only capable clients to turn off **IPv6** > only upon receiving an explicit signal from the network and operate > in dual-stack or IPv4-only mode otherwise. > > I think that "turn off IPv6" should be "turn off IPv4". Oh indeed! Will be fixed in -01. Thanks for pointing out! > -----Original Message----- > From: dhcwg On Behalf Of Jen Linkova > Sent: Wednesday, December 4, 2019 7:09 AM > To: dhcwg@ietf.org > Cc: draft-link-dhc-v6only@ietf.org; V6 Ops List > Subject: [dhcwg] IPv6-Only Preferred DHCPv4 option > > Hello, > > One of the biggest issue in deploying IPv6-only LANs is how to do it incr= ementally, when some hosts work just fine in NAT64 environment while some l= egacy devices still need IPv4. Doubling the number of network segments (hav= ing an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all dev= ices can co-exist in the same network segment and hosts capable of operatin= g in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 ad= dresses and deploying IPv4-as-a-service: > > Name: draft-link-dhc-v6only > Revision: 00 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-04 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6on= ly > > > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > address if the network provides IPv6 access. > > Any comments/suggestions/reviews are highly appreciated! > > Adding v6ops@ to Cc: as the problem is related to operating IPv6-only net= works. > > Thank you! > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 16:30:43 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFF712008A for ; Wed, 4 Dec 2019 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34cUyA6aciVs for ; Wed, 4 Dec 2019 16:30:39 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A84212003F for ; Wed, 4 Dec 2019 16:30:39 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 40504796 for ; Thu, 5 Dec 2019 00:30:36 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 0B72B1CD619; Thu, 5 Dec 2019 00:29:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575505780; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aTdJtT8krm7CSf8OYu6zxfF4oXG3YzRZPhCAyYjPTvE=; b=ndzzf1aUwgfFztywo7PhR+HG9UNCpJIizaSaH07BkFvcy6CK1GEuAbDfXIDxAZ1Gch2KcW DambZcoKILnJChniS+/V+jWwnFB+JcXEY5jT78M3NlbI6YMbrrNyffjOT99i4MUXSmJr6B 2gEBkCL9b9VTVPaVkJhGFAwhNOOREdU= To: Jen Linkova , dhcwg@ietf.org Cc: draft-link-dhc-v6only@ietf.org, V6 Ops List References: From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 00:30:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 00:30:41 -0000 Hi Jen! I maintain dhcpcd, a fairly popular DHCP and DHCPv6 client. On 04/12/2019 12:09, Jen Linkova wrote: > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. Doubling the number of > network segments (having an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all > devices can co-exist in the same network segment and hosts capable of > operating in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > addresses and deploying IPv4-as-a-service: I disagree with a fair chunk of this. It assumes that IPv6 is the be-all and end-all. Maybe one day we will have IPv8? It would be much better to say that DHCP as a whole is disabled. See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair enough because it's all IPv4 addresses. Set both options and you're golden. BUT - what if we need to enable DHCP again? Should clients still listen for FORCERENEW? It does pose a small dilema because there isn't actually anything to renew. So maybe we could let this new option fit in with T1 and T2 timers (well, effectively T2 as there's no address to unicast from) and you can even set this to infinity if you wanted to. Roy From nobody Wed Dec 4 16:53:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9F212008A for ; Wed, 4 Dec 2019 16:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQp-R-gvd0PK for ; Wed, 4 Dec 2019 16:53:03 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::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 05813120018 for ; Wed, 4 Dec 2019 16:53:03 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id v140so1181874oie.0 for ; Wed, 04 Dec 2019 16:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KyrZrIlhCUnpsGBU7tDFGofV8L6wVVrrhCOQ/xbzZX0=; b=YGEcmhQoKFnLaMydh5hd9QgeTYuMzZZS45tEVdmiGCRJAffpAQ2jNS1QW+qwB+o/dS zNCJ88pzA+GsR86StO60pKEOSbvrNv6kgypqTpLSyWiiwf4aKXKtO1BdNARy6jws1+sb nT+cly5sq0/yqVKn8qFt83CoSdTRRsmY2DHjl0ZqoE3bjy1eLQrzc5rzSKO9f0QnscQz n0fslnER5/txEfW+watLnYfUngvzCnEaMaW/uo4bkC2qkCmMwI2c8bgbBXWl8uIw4DRG 43QPfZJRM3fjyQ5busFZtxQXKyJg4GOQtSf6ZdL+3JfFaEA4pgJGJpT/EFteNZGSXhHu wnsw== 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=KyrZrIlhCUnpsGBU7tDFGofV8L6wVVrrhCOQ/xbzZX0=; b=Y0kyj8u537+keIFVXureTuT5BxOktkdpj4OWbHhjYhaf6g87vYKn47/+gX2ZrMkSRg P8rYRxdk5UHGkipfGMBEEIUevHk3vtLJA4OkNlcXk6Am7IQcYSFhWcSgYb1R0C/VYilm iU4x3c1rMGOmjs+VP2Qn405aYzYaeeIdIhmA7rQTjgG4o6J9Xw0zrzImkOdCWJ5kUlvN 1CUPnfFeq8cF3mCcwrbfLEdSLMiChxdtBxfEwoL47r4hd4PSu4Nd76GK1f7vlAu4lnv3 Ja3EeseEWk8hmD5DR5FEkTF4FP8bJczJGVddqsFnafFTEiHD0nMbBsOa9g45iN5WqjYw ApTA== X-Gm-Message-State: APjAAAUNpq1Gvf6xTgg/zBzPEmL6DXeKqnRRymIYyL6128Z3LFj/TUgg 3Vse0J2INZj2HC/j1h+w/ybyKZQN9Siv2dY08Ok= X-Google-Smtp-Source: APXvYqwRNy4bAEFfG2DJK19xeyhvs8+FuNIwRE4RlsGabtFkm+D2u30ZZn8HfhQCBGqiakg/Qv7CtxrUzH3blJir1t8= X-Received: by 2002:a05:6808:98d:: with SMTP id a13mr5197123oic.7.1575507182300; Wed, 04 Dec 2019 16:53:02 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: From: Mark Smith Date: Thu, 5 Dec 2019 11:52:35 +1100 Message-ID: To: Lorenzo Colitti Cc: Nick Hilliard , v6ops list Content-Type: multipart/alternative; boundary="000000000000f131180598ea5949" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 00:53:05 -0000 --000000000000f131180598ea5949 Content-Type: text/plain; charset="UTF-8" On Thu, 5 Dec 2019, 10:57 Lorenzo Colitti, wrote: > On Thu, Dec 5, 2019 at 5:43 AM Nick Hilliard wrote: > >> > As an ex-author of an ex-draft that suggested using IPv6 to tell >> > hosts to avoid IPv4, I'm curious to know whether a draft that >> > suggests using IPv4 to tell hosts to prefer IPv6 will also be accused >> > of being an operational nightmare. >> >> I haven't read the draft yet - and won't get to it for a couple of days >> - but am also curious about why this approach is better than the other >> way around :-) >> > > Here are a couple of reasons why we believe this proposal will fare better > than the IPv6-only flag: > > 1. It has a clear goal and clear semantics. There was little > consensus on the meaning of the IPv6-only flag. Did it mean that there was > no IPv4 on the link? That the network should not provide IPv4 addresses? Or > that hosts should never send packets with IPv4 ethertypes? If the latter, > why not drop the packets in the infrastructure? But then, what > about link-local? And so on. In contrast, this option's goal is very clear > (conserve IPv4 addresses) and its meaning is very clear: here's an IPv4 > address if you want it, but please don't use it if you don't need it. > > So I haven't read the draft either, although the following applied in the context of the the IPv6-only flag draft and I think this one. Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first application opens an IPv4 (or IPv6) socket, and then released when the last application closes the last IPv4 socket? It seems to me that it is really only tradition that devices acquire network layer addresses when the host boots up or when an interface attaches to a new link. Devices are acquiring addresses even though there may never be applications running on the host that use the address. If hosts only acquired IPv4 addresses via DHCPv4 based on when the first IPv4 application started running, then when a host is only running IPv6 only applications, it would never acquire an IPv4 address because it wouldn't need one, meaning never try to use DHCPv4 (so would avoid the link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requests). If all IPv4 on-demand hosts on a link are then only running IPv6 only applications, IPv4 would not ever appear on the link. Hosts would effectively switch off IPv4 on links themselves because they don't need it. More generally, IPv4 would automatically drain away from networks more hosts exclusively running IPv6 only applications appear. In this scenario, there would be no need for any out-of-band signalling mechanism to say switch off IPv4, such as what this draft proposes or what the IPv6-only RA flag draft proposed. Some might say they want hosts to acquire addresses for security purposes of knowing what devices are on a link. However, I can attach to a link, purposely not acquire an IPv4 (or an IPv6) address, yet spoof packets with IPv4 or IPv6 addresses. In other words, if you truly want to have an audit trail of devices that attach to your link/network for security purposes, you need to do it at layer1 and/or layer 2 at the point of attachment of the device, not layer 3. > 1. It is using a protocol that already configures IPv4 to configure > IPv4. The IPv6-only flag was trying to affect IPv4 using an IPv6 protocol, > and that allows attackers to mount attacks on existing networks that have > not deployed IPv6 and thus have no IPv6 security measures in place. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000f131180598ea5949 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 5 Dec 2019, 10:57 Lorenzo Col= itti, <lorenzo=3D40google.com@dmarc.ietf.org> wrote:
On Thu, Dec 5, 2019 a= t 5:43 AM Nick Hilliard <nick@foobar.org> wrote:
> As = an ex-author of an ex-draft that suggested using IPv6 to tell
> hosts to avoid IPv4, I'm curious to know whether a draft that
> suggests using IPv4 to tell hosts to prefer IPv6 will also be accused<= br> > of being an operational nightmare.

I haven't read the draft yet - and won't get to it for a couple of = days
- but am also curious about why this approach is better than the other
way around :-)

Here are a couple of rea= sons why we believe this proposal will fare better than the IPv6-only flag:=
  1. It has a clear goal and clear semantics.=C2=A0 There was= little consensus on the meaning of the IPv6-only flag. Did it mean that th= ere was no IPv4 on the link? That the network should not provide IPv4 addre= sses? Or that hosts should never send packets with IPv4 ethertypes? If the = latter, why not drop the packets in the infrastructure? But then, what abou= t=C2=A0link-local? And so on. In contrast, this option's goal is very c= lear (conserve IPv4 addresses) and its meaning is very clear: here's an= IPv4 address if you want it, but please don't use it if you don't = need it.

So I haven't read the draft either, alt= hough the following applied in the context of the the IPv6-only flag draft = and I think this one.

Why aren't = IPv4 (and IPv6) addresses acquired on-demand when the first application ope= ns an IPv4 (or IPv6) socket, and then released when the last application cl= oses the last IPv4 socket?

It seems to me that it = is really only tradition that devices acquire network layer addresses when = the host boots up or when an interface attaches to a new link. Devices are = acquiring addresses even though there may never be applications running on = the host that use the address.=C2=A0

If hosts only= acquired IPv4 addresses via DHCPv4 based on when the first IPv4 applicatio= n started running, then when a host is only running IPv6 only applications,= it would never acquire an IPv4 address because it wouldn't need one, m= eaning never try to use DHCPv4 (so would avoid the link-layer broadcast DHC= P_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requests).= =C2=A0

If all IPv4 on-demand hosts on a link are t= hen only running IPv6 only applications, IPv4 would not ever appear on the = link. Hosts would effectively switch off IPv4 on links themselves because t= hey don't need it.

More generally, IPv4 would = automatically drain away from networks more hosts exclusively running IPv6 = only applications appear. In this scenario, there would be no need for any = out-of-band signalling mechanism to say switch off IPv4, such as what this = draft proposes or what the IPv6-only RA flag draft proposed.

Some might say they want hosts to acquir= e addresses for security purposes of knowing what devices are on a link. Ho= wever, I can attach to a link, purposely not acquire an IPv4 (or an IPv6) a= ddress, yet spoof packets with IPv4 or IPv6 addresses. In other words, if y= ou truly want to have an audit trail of devices that attach to your link/ne= twork for security purposes, you need to do it at layer1 and/or layer 2 at = the point of attachment of the device, not layer 3.
=
  1. It is u= sing a protocol that already configures IPv4 to configure IPv4. The IPv6-on= ly flag was trying to affect IPv4 using an IPv6 protocol, and that allows a= ttackers to mount attacks on existing networks that have not deployed IPv6 = and thus have no IPv6 security measures in place.
_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f131180598ea5949-- From nobody Wed Dec 4 16:58:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08112008B for ; Wed, 4 Dec 2019 16:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NunOaz-FD6Os for ; Wed, 4 Dec 2019 16:58:13 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E37D12008A for ; Wed, 4 Dec 2019 16:58:13 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 47Sy506zXQz9vbLF for ; Thu, 5 Dec 2019 00:58:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6juxT28v96wL for ; Wed, 4 Dec 2019 18:58:12 -0600 (CST) Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 47Sy505RQdz9vKfH for ; Wed, 4 Dec 2019 18:58:11 -0600 (CST) Received: by mail-qk1-f197.google.com with SMTP id t185so1093761qkd.2 for ; Wed, 04 Dec 2019 16:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BFKbVvg8gdkpq9ybw0WcvO4WBSkOq4gBrIuuszmLEWY=; b=g1hOtdJozEOiMV5TK3BvxQNNKrux4+CalPlr4VqhWA0xKZeKLMzeB8LPs72QY+W09u Xfalgb6TbiOCeJ7sPq8OvCoVkPI4xLMZNOG/2L4IbaKVe41PUS/+lUO4ueSEBQloyox+ hs1hANGkT+2NxsbOw1IDi/vZmiDULKKYTXfh96jWg/jG+1aMB8dhmNcZ6WsdczYEzFtr a0PX9zMJCq47SJ3vUe51e72pRwlk0e2mKxwDuF8WW85V3lhh3I/GWV9eJVTgGOvU/uV3 0iPTFN7ITc/U8b+ch5rY1336OB7NEjpKFxviYIXbIgYe/kBK6zlk1oJ/Mcid2jNf/7N1 75NA== 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=BFKbVvg8gdkpq9ybw0WcvO4WBSkOq4gBrIuuszmLEWY=; b=F5XvOwn2hxY5g7OpcznI5/Qdze2fWP5PMaoiIWt3D1qfXHKA/0XTBuMhy68Dtaj0fT JPqLFEC5/2h72HIsKKDNBS5+f71UKjRKPDA7eW+U3pG5G0bLyrnUv1WWXj9tF5jLtAKi nruTmkjSL+dK459j15g9To/yi6TBec6N38DWoqqXs5GPYNptVtNZy6lswHovVqtPQxtg 0d/IGoXTcvQI3JmONqsh+7ywyDPujwLg6N9A0B3RbtBS0kxdVSidMzsy6cJcRz62GyQ5 eCzYDi4GKVu4pRyH/q0dJK5tPhgOSB+W0bvuAagiih9qoB4wTmarO9WBoQe/tuNOmsgb AUdQ== X-Gm-Message-State: APjAAAWub51/Rz5+8PbtO6OX51wr30hkGMx3xwiJXVBdTp26RHU/jC2i JhKLfCu782oXjG12/gTwM3ezG9btNUViNWc6sBP3i3oj8h/PZyavPpmQYOu8WWuHUbbKCayxNme J8PGgOEBZJD0xsv0OWcGQrzZd+g== X-Received: by 2002:ae9:e109:: with SMTP id g9mr5892129qkm.141.1575507490568; Wed, 04 Dec 2019 16:58:10 -0800 (PST) X-Google-Smtp-Source: APXvYqxdVaSsR0C5Wg2vH9xmzsBnSm1YMcv/xUKPdSqbxHASA/A03zQ030GbFVKke+21RW0bMJn7E71uFMg3GNKz5hU= X-Received: by 2002:ae9:e109:: with SMTP id g9mr5892109qkm.141.1575507490121; Wed, 04 Dec 2019 16:58:10 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: David Farmer Date: Wed, 4 Dec 2019 18:57:53 -0600 Message-ID: To: Jen Linkova Cc: Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a46b50598ea6c44" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 00:58:15 -0000 --0000000000004a46b50598ea6c44 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 4, 2019 at 5:07 PM Jen Linkova wrote: > On Thu, Dec 5, 2019 at 5:22 AM Michael Richardson > wrote: > > A question that we had was whether or not hosts in a IPv6-mostly network > > should configure IPv4-LL addresses in order to speak to legacy-v4-only > hosts. > > Actually the more I think about it the more I believe the host should > be doing whatever they are doing w/o DHCPv4 presence. > Android does not configure IPv4 link-locals, MacOS does. Making the > same OS behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server > responded with IPv6-only Preferred option") might be undesirable. As > an operator I'd expect that IPv6-only capable host would behave the > same way on a dedicated IPv6-only segment and on IPv6-mostly segment. > Regarding IPv4-LL, I like Roy Marples suggestion of combining this with RFC 2563 to determine if a host is to configure an IPv4-LL, and in that case, the address returned should be 0.0.0.0. Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by a server "if the IPv6-only Preferred option is present in the Parameter Request List received from the client and the corresponding DHCP pool is explicitly configured as belonging to an IPv6-mostly network segment" as discussed in Section 3.3? Thanks > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --0000000000004a46b50598ea6c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 4, 2019 at 5:07 PM Jen Li= nkova <furry13@gm= ail.com> wrote:
On Thu, Dec 5, 2019 at 5:22 AM Michael Richardson <mcr+ietf@sandelman.ca>= ; wrote:
> A question that we had was whether or not hosts in a IPv6-mostly netwo= rk
> should configure IPv4-LL addresses in order to speak to legacy-v4-only= hosts.

Actually the more I think about it the more I believe the host should
be doing whatever they are doing w/o DHCPv4 presence.
Android does not configure IPv4 link-locals, MacOS does. Making the
same OS behaving differently ("no DHCPv4 whatsoever" vs "DHC= Pv4 server
responded with IPv6-only Preferred option") might be undesirable. As an operator I'd expect that IPv6-only capable host would behave the
same way on a dedicated IPv6-only segment and on IPv6-mostly segment.

Regarding IPv4-LL, I like Roy Marples sugges= tion of combining=C2=A0this with RFC 2563 to determine=C2=A0if a host is to= configure an IPv4-LL, and in that case, the address returned should be 0.0= .0.0.

Also, is there any reason that 0.0.0.0 shoul= dn't be the address retunded by a server "if the IPv6-only Preferr= ed option is present in the Parameter Request List received from the client= and the corresponding DHCP pool is explicitly configured as belonging to a= n IPv6-mostly network segment" as discussed in Section 3.3?
=
Thanks
=C2=A0
--
SY, Jen Linkova aka Furry

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


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000004a46b50598ea6c44-- From nobody Wed Dec 4 17:01:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98B612003F; Wed, 4 Dec 2019 17:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICurXUWdFLLH; Wed, 4 Dec 2019 17:00:57 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0598C120018; Wed, 4 Dec 2019 17:00:57 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id x1so1822407qkl.12; Wed, 04 Dec 2019 17:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WfsSSf1Lsvbv120W0rBBD5sKOiH6KEn/bFUEQaSAqls=; b=JlBHzCWNrZu5KTwbhrLORUORfccN+p1YbA5xzvSCuTIkBdbseS2dW0iawW2fUKyUWZ byiVzLJ3qtlx1tTUyDBdmjc8k9E9OnRRrC1ZwJHkUeDIZCvyDp2WUdVQF4pJFSeui9PA iPeCm0VWJ5dTmSmhDu/vWyL0SpeSzuFn0bJgpOUXIER75JiOszRQq/34h1icroGLjckd jtS3NZeF+SkoryXFfU5qqgioirukVQ6+1haDIgm4TkAGq8mnMQkr0xlk59of0/49/EG+ xFkbRSzJnvkM8z4++4cKEmpnM7uLdyoTSZbRfE/0QmEEK1yL4lroZifNbBMMzlTIjOMg BULg== 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=WfsSSf1Lsvbv120W0rBBD5sKOiH6KEn/bFUEQaSAqls=; b=Q0DAtJ1QxkPSOTc1/pSXePHkkxIcm51hljzbeY36TLmb131IyN77XLG00nJW26k4Jj DxyK1qlpV9rOwi6MgEsyFHhbiY0ik/4eImPvGwx6Kgvyv4hMdWgcwSl3tPGA5UnjIRl/ D6RAbfEtO2e7d2wye57JiN/ek0xJY13v5fnRto0VJBbNRZcvg4DkYrRtddUm4/8kXxWv HRhQPqLHVaJy1kom+FSVdiiQHjA7VrBwbkOKOAwgggwWki2HsvC6mXRkTCQyb42PQJ6g PcOTYuicmGZu9/1sPhe4Qzqd/r74k2iDJYfNBcyOp+1FTcPzkBQE0Z834Y5+gG69EJrS FRdQ== X-Gm-Message-State: APjAAAW3XVYTILJkLkRv8Ksvv3l4NuuSMiH3dS/YT5Udm5aFZy2UtHdA EpC6neucFkam7LNaMgCi2v/Cdi8+vGopbJrvA4WPFwt3 X-Google-Smtp-Source: APXvYqyKxuhilwdVMra3JWkfZdURPwVBQaNPIFp/76LXD73Fe/HSW9FjXLK3d7O7g7v+I5lxQobHb/UrVHrXbuhyEWA= X-Received: by 2002:a37:7686:: with SMTP id r128mr4912513qkc.277.1575507655764; Wed, 04 Dec 2019 17:00:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 12:00:43 +1100 Message-ID: To: Roy Marples Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:00:58 -0000 Hi Roy, On Thu, Dec 5, 2019 at 11:30 AM Roy Marples wrote: > > One of the biggest issue in deploying IPv6-only LANs is how to do it > > incrementally, when some hosts work just fine in NAT64 environment > > while some legacy devices still need IPv4. Doubling the number of > > network segments (having an IPv6-only and dual-stack segments of each > > type) is an operational nightmare. So it would be just awesome if all > > devices can co-exist in the same network segment and hosts capable of > > operating in IPv6-only environment do not consume IPv4 addresses. > > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > > addresses and deploying IPv4-as-a-service: > > I disagree with a fair chunk of this. > It assumes that IPv6 is the be-all and end-all. Maybe one day we will > have IPv8? Oh I do hope that by the time we start deploying IPv8-only networks we'll be done with IPv4 ;)) On a serious note: if one day we discover that we also have other scenarios (in addition to IPv6-only networks) when we might want to provide IPv4-as-a-service, the proposed mechanism still can be used I believe. While the draft keeps mentioning IPv6-only and NAT64 as a prerequisite for disabling IPv4, it's only because it's the only use case exist today. If I wake up tomorrow to find out that we have IPv2020 and majority of my devices can operate on IPv2020-only while I still have to provide IPv4 for some hosts, we can do 's/IPv6/IPv2020/g' in the text. > It would be much better to say that DHCP as a whole is disabled. Sorry, I'm not sure I understand. The draft is proposing that if a client is willing to live w/o IPv4 and the server confirms that IPv4 is optional on the network segment, the client is disabling DHCP for some time. What would you like us to change? > See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair > enough because it's all IPv4 addresses. Set both options and you're golden. > > BUT - what if we need to enable DHCP again? Should clients still listen > for FORCERENEW? It does pose a small dilema because there isn't actually > anything to renew. The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT seconds. -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 17:03:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835012003F; Wed, 4 Dec 2019 17:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k7haSqJSUGo; Wed, 4 Dec 2019 17:03:04 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C98120018; Wed, 4 Dec 2019 17:03:04 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id b5so1785581qtt.11; Wed, 04 Dec 2019 17:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QRpbjfoQ8JKlAjjonavZV+eHNfEoZUCae0vGw3ZMAgg=; b=XgFr2E9DdGDntItFhZU5XNx/RwCREnuNlvm3QP9SI4oz8fk0Ejd3A2svxk3Wh6U/sb uR1b6N6n1uO7u4jKL1zOFNh7jlQ1Lv29OhYuJBbiSuEXVH99BVEh1E95aPefwybnFqk2 JXbcs9sXd2SqvzziZb72UK7i4GvxxbhJsVzJk92+tFILuicaDsKpdn+7TR9xS/UqOOKW V4OhgLxjNAZlMPbEiRWLW1shaMzbMdeaxN+9NQwHHhu5HbJ0KGRW1i98Xsz4ZtKBmVo0 MkZmLl+2h3hWOvPWgWB64BxkDNNBYVvvfOKyeKj23hFtkO/wkvYfUMPmeUbEJdAMCKab 7KDA== 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=QRpbjfoQ8JKlAjjonavZV+eHNfEoZUCae0vGw3ZMAgg=; b=gFdR3TqqTu/k0IT47SIHUj3InpCVKq7L/J9870FBUiyFyx4FlvbmTQF1LY3qvFgPre 8lmX2OjVR09pLYYSyDAqeBjFuevzuTPgg6LAxxspK/guKJE3qdSaV6Ihc7ZizXXbWiPE /1DCetDUR9tu9rKuqkaBB6p3LB/vsZ84gZ/pgamIqRn9qnJDb1Jj1lXt40ZFImxggxeg bH5OFcAVPTJvsynP/9XxuagtTONnzFv2PEzoS2y2nM/wg/1d6oaLWsRpazCnXD+1bCIK j14lQOJDzlao9vudFSTjP575W1c+383pNouVnMcdX5s2iJ3iju4UwRN0ymgSGnb0sdK1 UPMQ== X-Gm-Message-State: APjAAAVkhd9krF0L9/w06pRj4sDY4sd6qFxDKCm5hKRKWRwPZzuhfIRu qo6yBzHr/bYSTIlhM6jVvzb5+3zFsQtyQuXBxaY= X-Google-Smtp-Source: APXvYqzB2vC/u2+8D8LkxwYwh4weAY8qloMR7CTE08SclV/KXC9OKol1TraL5xKu7G7lPYK5NG48EvqKz2KHyiog+xk= X-Received: by 2002:ac8:1017:: with SMTP id z23mr5359738qti.94.1575507783675; Wed, 04 Dec 2019 17:03:03 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 12:02:52 +1100 Message-ID: To: David Farmer Cc: Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:03:05 -0000 On Thu, Dec 5, 2019 at 11:58 AM David Farmer wrote: > Also, is there any reason that 0.0.0.0 shouldn't be the address retunded = by a server "if the IPv6-only Preferred option is present in the Parameter = Request List received from the client and the corresponding DHCP pool is ex= plicitly configured as belonging to an IPv6-mostly network segment" as disc= ussed in Section 3.3? We discussed that but some concerns were raised - allegedly it might make some DHCP-snooping switches very unhappy. --=20 SY, Jen Linkova aka Furry From nobody Wed Dec 4 17:09:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D68120935 for ; Wed, 4 Dec 2019 17:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGYM02CzofTc for ; Wed, 4 Dec 2019 17:09:20 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12067120934 for ; Wed, 4 Dec 2019 17:09:20 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 47SyKq4hJGz9vklK for ; Thu, 5 Dec 2019 01:09:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNM3PyoUX2S3 for ; Wed, 4 Dec 2019 19:09:19 -0600 (CST) Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 47SyKq3Hbcz9vLGv for ; Wed, 4 Dec 2019 19:09:19 -0600 (CST) Received: by mail-qt1-f199.google.com with SMTP id m30so287846qtb.2 for ; Wed, 04 Dec 2019 17:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iF68JzWa2rUNRpgNH+HNhN4DSSuyv1f9iPnpROpnD2s=; b=nhwDCPxlKjmk5cg3MXp2FGSlZyDEipdyxDOag/X/DMmZsaVixdASS8ksfs5jpmOy3A 8uoYR1aWIrrh6eL9cKXdqZrCdPffowTpwT/Y59lyFRu4/n0cZwvPkdbyY5LR2GMJzxVs NmY6yhzDXYfDyVw0P0+mZCABND48hLBnRjRnJdjtX25UJgCGY2YGae6ruHwGGo9IHVSS 7+f3A+SZkPEC78fjJA6sB87EVgKupiscdlIdmeAv7khn4Z1US9AQDgDLbAYpa79SzCLb OmYbm6OeMhB5aXF98NuNXBtBEYcRq3J8C3XaQfvjDB/GSjiDV5IoS/XBaEDu2O8AQsh7 PnOA== 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=iF68JzWa2rUNRpgNH+HNhN4DSSuyv1f9iPnpROpnD2s=; b=W9QZzZjsZgvWP7WFbKAfGRrEkYN0NXKXSS3uJ/3PAxhcHHd3rUKcGCGbz5sMAtQi7N 5tQ8WLsyI2Y1z2dz2xvZUkzctEVD3EvlZa05zxQScfheoYFNd+Pbk+LW6AvIVAyv6nGy DyZlNIFDbStF+Wmbnyqxevvm0chZQ/UOJHOOvZbeYIUblTGaD2NU79TMpEpNCh10VKDP 0gQ19hIZffJ4c40FcQbSCBboNnvKFO2SktGlsU+VcNvWF+UaFZmWRlz0Jr4uW0vNF22N 4Kbp2tl9yndn+bexRpREy7dt8UBJFKONts29PsgSJhLXV/Q72+VTUVNDbjZO9pIIej6K Gn9Q== X-Gm-Message-State: APjAAAWtKUFm1QPnj9JPS3zkGlWwMYzBR04M/ZEQn/XGh1wxvCXOw/gp U0rVrbD5L3YSofWz+clnLL1q9ruYoO+Nrake7jGug1cuwBuf3DYwu6u26ACBcjq8qjFAKjPUz01 W3rZtTbNYRzGmI+mM4sLRVaacfA== X-Received: by 2002:aed:20c3:: with SMTP id 61mr5619139qtb.392.1575508158154; Wed, 04 Dec 2019 17:09:18 -0800 (PST) X-Google-Smtp-Source: APXvYqz8awk5bk+0ErOvc80UvhIhGfoGUNHWer2TqK3XjdKHVStiA+cQ21H1wOaAwv/OhHBygo4uCanjtWzmoTyhDw0= X-Received: by 2002:aed:20c3:: with SMTP id 61mr5619044qtb.392.1575508157554; Wed, 04 Dec 2019 17:09:17 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: David Farmer Date: Wed, 4 Dec 2019 19:09:01 -0600 Message-ID: To: Jen Linkova Cc: Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: multipart/alternative; boundary="0000000000001279d10598ea9476" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:09:21 -0000 --0000000000001279d10598ea9476 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 4, 2019 at 7:03 PM Jen Linkova wrote: > On Thu, Dec 5, 2019 at 11:58 AM David Farmer wrote: > > Also, is there any reason that 0.0.0.0 shouldn't be the address retunded > by a server "if the IPv6-only Preferred option is present in the Parameter > Request List received from the client and the corresponding DHCP pool is > explicitly configured as belonging to an IPv6-mostly network segment" as > discussed in Section 3.3? > > We discussed that but some concerns were raised - allegedly it might > make some DHCP-snooping switches very unhappy. > If that is really the case then I think some discussion on selecting the address returned is probably needed in the draft. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --0000000000001279d10598ea9476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 4, 2019 at 7:03 PM Jen Li= nkova <furry13@gmail.com> wr= ote:
On Thu, Dec= 5, 2019 at 11:58 AM David Farmer <farmer@umn.edu> wrote:
> Also, is there any reason that 0.0.0.0 shouldn't be the address re= tunded by a server "if the IPv6-only Preferred option is present in th= e Parameter Request List received from the client and the corresponding DHC= P pool is explicitly configured as belonging to an IPv6-mostly network segm= ent" as discussed in Section 3.3?

We discussed that but some concerns were raised - allegedly it might
make some DHCP-snooping switches very unhappy.

If that is really the case then I think some discussion on selectin= g the address returned is probably needed in the draft.

Thanks.
=C2=A0
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000001279d10598ea9476-- From nobody Wed Dec 4 17:12:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176AD1200B9 for ; Wed, 4 Dec 2019 17:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDmxCc1WzMwE for ; Wed, 4 Dec 2019 17:12:19 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [77.68.23.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 515CD120946 for ; Wed, 4 Dec 2019 17:12:19 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id CEE6E795 for ; Thu, 5 Dec 2019 01:12:13 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 084CF1CD619; Thu, 5 Dec 2019 01:11:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575508277; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AVlaZf7GFFDHGErESitGhSULXqybjZIiC/XckK38sM4=; b=RQLGtq2xqXRoR2CAYbhJpzAJRp6cXI/S7ZXHdAhuKhpV7pdp8M1rndfOJxTwWj0t66hges 06E6oAAW5nrkMtExCDShr43KCMCMerAzZ0JxdmLMim8uQ1jpoKXKhNdOxhKfrP0uFHRac1 jGeiG25GEVWvsfPGbfMwSVQzEJhckRo= To: Jen Linkova Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List References: From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 01:12:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:12:20 -0000 On 05/12/2019 01:00, Jen Linkova wrote: > While the draft keeps mentioning IPv6-only and NAT64 as a prerequisite > for disabling IPv4, it's only because it's the only use case exist > today. > If I wake up tomorrow to find out that we have IPv2020 and majority of > my devices can operate on IPv2020-only while I still have to provide > IPv4 for some hosts, we can do 's/IPv6/IPv2020/g' in the text. > >> It would be much better to say that DHCP as a whole is disabled. > > Sorry, I'm not sure I understand. The draft is proposing that if a > client is willing to live w/o IPv4 and the server confirms that IPv4 > is optional on the network segment, the client is disabling DHCP for > some time. > What would you like us to change? Just the wording basically. It assmues only IPv6. I dislike it when different protocol families discuss each other - IPv6 should not turn off IPv4, likewise IPv4 should not turn off IPv6. I would prefer it if Iv6 was not mentioned at all outside of a use case for the option. "The network" should say if each protocol should be used *for* each protocol. I know for sure that there are other network protocols at the equivalent OSI layer - sure not as popular as IPv6 but why exclude them as well? > >> See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair >> enough because it's all IPv4 addresses. Set both options and you're golden. >> >> BUT - what if we need to enable DHCP again? Should clients still listen >> for FORCERENEW? It does pose a small dilema because there isn't actually >> anything to renew. > > The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT seconds. Is the wait seconds even needed? Just set the T2 timer and treat it as leasing the unspecified address. Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides nothing of value as I see it. Roy From nobody Wed Dec 4 17:16:26 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBB9120111 for ; Wed, 4 Dec 2019 17:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPZI4-GBRc67 for ; Wed, 4 Dec 2019 17:16:19 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [77.68.23.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 BA9C71208F2 for ; Wed, 4 Dec 2019 17:16:18 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 1A4A6797 for ; Thu, 5 Dec 2019 01:16:17 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 405061CD619; Thu, 5 Dec 2019 01:15:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575508520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DT7KzOBJsFo5zVQr5RyCXKil1+71//Fwzz5G6ukDz7U=; b=e/oF3qHruY4860Skm/UQlSt9A2bPKic5THFQPpM06n1t3NIMXubJm2rm0mtJ/l5y8O99d2 TenXvht3deuzMMnqnjMnHK0V46LeFpiXEuZz96T2AXCPzJDmTJQ3PNqUB3BQif1d5xLW1T Hp4R/lxZHQ/hHRqWx9RShJuTxYmAgPg= To: Jen Linkova , David Farmer Cc: Michael Richardson , V6 Ops List , draft-link-dhc-v6only@ietf.org, dhcwg@ietf.org References: <28594.1575483729@localhost> From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 01:16:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:16:20 -0000 On 05/12/2019 01:02, Jen Linkova wrote: > On Thu, Dec 5, 2019 at 11:58 AM David Farmer wrote: >> Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by a server "if the IPv6-only Preferred option is present in the Parameter Request List received from the client and the corresponding DHCP pool is explicitly configured as belonging to an IPv6-mostly network segment" as discussed in Section 3.3? > > We discussed that but some concerns were raised - allegedly it might > make some DHCP-snooping switches very unhappy. I quickly skimmed RFC2131 and nothing is mentioned about any assigned address being unspecified or otherwise invalid. So as I see it, what the client should do is Unspecified Behaviour. We could treat it as any other standard and define it. It's not as if current implementations don't barf on current RFC's ..... Roy From nobody Wed Dec 4 17:20:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00FD120111; Wed, 4 Dec 2019 17:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wo4TklzHpuv; Wed, 4 Dec 2019 17:20:05 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::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 6178D120047; Wed, 4 Dec 2019 17:20:05 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id c16so1216865oic.3; Wed, 04 Dec 2019 17:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qSV2vIKyA+/dJTywq4Rua0Z1cM+VOk4GRHCyh4v9vpI=; b=q/coOntia5vgbwkgh6ZVvFgi+9BYpyhinkCqx/yand4VwbHDEQfiyO3roiITpKOJnD ckky/CGryTCfYu+58QPbrzbiTu+salAf/M/8vTn/jC4DpditS8inENIplLwglSTXUE8+ aklxo7MgpEa57F4bGALqP1P3L44xt50ycxoFdLxs11v9QLgCXjJN9SWE5Q5Ef1QA3SWS tj/MjvZwHbnVU0GfgjAj0Mf8mEyFgEjn2nzR+ZgVP4t/VppfUi14KLIpAg2nnFb6mYz3 /p5k+hUhn/EiEk7lEGWs+9pWY75aj0MbCSm3r2lnDcIHzeH+UwDul/IDaswtODSqlXEl ztDg== 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=qSV2vIKyA+/dJTywq4Rua0Z1cM+VOk4GRHCyh4v9vpI=; b=NAa9euiuLW1oqaqjhDS7V3bpbi4OdvsAmA5JGjFIpcdAKDf329QKKKyzEZCwO8SmOO 5ejzFaZhbgqGjFFuGoUbe0mbdbrysjAXl2rLXdUbC5hu+xcfKSUZ8IgsiPgNidhCvw46 jJ8igLPVJD4TPjh7uRiCvZhR2k7yE/BMQwoAU9iHmgpQouD3I0eJ9Lpo+UfpKbydL9BX PQ84AOmmHENypjakqNcujecSJgjgSklMrGrGIujrp9gX2b8iI5UF62fkg/PFzDmdJOKA 4YQZGkSTZ47ZQHxq8p8dVRfI9hkLTLhiZAC0HLFE+bi6aynnzU02966OOiTruCi/3kav XnVQ== X-Gm-Message-State: APjAAAUn+wYbyVEcg5gYoaWkrIthHZ8/UNuW2k9pqsSSfGPS4lkIWSsW 5D9qyha1fjkLPkhV6ZZlZfplx9KtcUFVuGLdUC7rAw== X-Google-Smtp-Source: APXvYqyYQnWgaywjQSFuZ39ohI6ngaOuCxZXCpmUPIWIYXOgWGGS1B7VcU1lLg/QN+v4G7Cm5K/U3TnY6Etap192jNs= X-Received: by 2002:aca:ef85:: with SMTP id n127mr5333812oih.54.1575508804691; Wed, 04 Dec 2019 17:20:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Thu, 5 Dec 2019 12:19:38 +1100 Message-ID: To: Roy Marples Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:20:07 -0000 On Thu, 5 Dec 2019 at 11:30, Roy Marples wrote: > > Hi Jen! > > I maintain dhcpcd, a fairly popular DHCP and DHCPv6 client. > > On 04/12/2019 12:09, Jen Linkova wrote: > > One of the biggest issue in deploying IPv6-only LANs is how to do it > > incrementally, when some hosts work just fine in NAT64 environment > > while some legacy devices still need IPv4. Doubling the number of > > network segments (having an IPv6-only and dual-stack segments of each > > type) is an operational nightmare. So it would be just awesome if all > > devices can co-exist in the same network segment and hosts capable of > > operating in IPv6-only environment do not consume IPv4 addresses. > > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > > addresses and deploying IPv4-as-a-service: > > I disagree with a fair chunk of this. > It assumes that IPv6 is the be-all and end-all. Maybe one day we will > have IPv8? > Going by the now almost entire lack of existence of Appletalk, IPX, DECNET, XNS, VINES (I haven't seen or heard of any of them in a network since 1999), it's likely IPv6 will be the single network layer protocol in the future. Running a single network layer protocol is cheaper and easier, which is why those others have gone away (that also explains why nearly all links use or emulate (Wifi) Ethernet framing, unless they specifically can't). IPv6 will have a life, just as IPv4 has had a life, and those other past protocols have had a lives. IPv6 is designed to last for much longer than almost any of them, centuries most likely, so I don't think we shouldn't be worrying about accommodating "IPv8" now at the cost of making IPv4 easier to move away from. We don't have any idea what "IPv8"'s transition requirements are or what it will even look like. > It would be much better to say that DHCP as a whole is disabled. > See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair > enough because it's all IPv4 addresses. Set both options and you're golden. > > BUT - what if we need to enable DHCP again? Should clients still listen > for FORCERENEW? It does pose a small dilema because there isn't actually > anything to renew. > > So maybe we could let this new option fit in with T1 and T2 timers > (well, effectively T2 as there's no address to unicast from) and you can > even set this to infinity if you wanted to. > > Roy > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 4 17:37:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364BC120058 for ; Wed, 4 Dec 2019 17:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZiXUhUw94wL for ; Wed, 4 Dec 2019 17:37:01 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [77.68.23.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 B6F26120809 for ; Wed, 4 Dec 2019 17:37:01 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 4E3C8796 for ; Thu, 5 Dec 2019 01:37:00 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 6CEF81CD619; Thu, 5 Dec 2019 01:36:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575509763; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2Kx9+dAvmmDll0Rca+VkEIXQS6R9yjXWl43q+reJYoo=; b=kQsIyUEvxWZCKzVzuYbk08P7L9vR/4Q20eBjzdVccFOJLnMRXIKCAvJtpp5jDXWKQRix/7 5yCO49AXegM2eOBA9pqtYhDhXBGp8GRbS24MoTKn9hKY86qxiYtx/qcGB/irR611DDDaVF AoiV89JYV+3qPZzuqyE6wMupWz5aJx4= To: Mark Smith Cc: dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org References: From: Roy Marples Message-ID: <6f8f4dbc-2f61-3aa9-16e9-cc6e6b11d246@marples.name> Date: Thu, 5 Dec 2019 01:36:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 01:37:04 -0000 On 05/12/2019 01:19, Mark Smith wrote: > Going by the now almost entire lack of existence of Appletalk, IPX, > DECNET, XNS, VINES (I haven't seen or heard of any of them in a > network since 1999), it's likely IPv6 will be the single network > layer protocol in the future. Running a single network layer protocol > is cheaper and easier, which is why those others have gone away (that > also explains why nearly all links use or emulate (Wifi) Ethernet > framing, unless they specifically can't). > > IPv6 will have a life, just as IPv4 has had a life, and those other > past protocols have had a lives. IPv6 is designed to last for much > longer than almost any of them, centuries most likely, so I don't > think we shouldn't be worrying about accommodating "IPv8" now at the > cost of making IPv4 easier to move away from. We don't have any idea > what "IPv8"'s transition requirements are or what it will even look > like. And this affects the wording and intent of my proposal how? 1 client sends DISCOVER with I CAN WORK WITHOUT DHCP ADDRESS option 2 server sends I HAVE NO DHCP ADDRESS option with T2 timer 3 client reads this and will retry in T2 seconds This satisfies the use case the OP put forward and makes no mention of any other protocol than DHCP AND makes things much simpler to actually implement. What did I miss? Roy From nobody Wed Dec 4 18:20:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94657120133 for ; Wed, 4 Dec 2019 18:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 IQ6IkNgoj_tc for ; Wed, 4 Dec 2019 18:20:05 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD000120043 for ; Wed, 4 Dec 2019 18:20:05 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id t17so1515924ilm.13 for ; Wed, 04 Dec 2019 18:20:05 -0800 (PST) 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=rok+rql13osFt4vlzhjGSzSPXXNPDvBxy13wbXdJWCs=; b=i86umn+m3pcEKXdbjc+Qkq3yUKnhAJCrncfdfF+g+clVVyuA46osHq+l0T0kJ3WcfP +ijrdlf8DOJM4WGTVoo2yzQ8O7UPPg9mnt4wQFCxPDdlv4SSlt0P/FxGdo0GSch0qiq8 5fidt3T1Ow7V48ajLVdin67ij7L33DDPzT+031radpd5Lzkwa3lqfq13EOZCiaqp1JJB 3a0JWcJY+oehJZwyweUionQrbpkweNMWnZq41nZ/0wUw1bMSOhmoR4/iGwYQAXCgwGtO 5LeGAvzG7m1/JAN6PEwiiTs7KBhjI62nz9onz8ot0ESzhjtYOZ77aQ4N4lYVpNXFS+wH sq+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=rok+rql13osFt4vlzhjGSzSPXXNPDvBxy13wbXdJWCs=; b=c+2Ed9Mt8SZK1aE3Cy1JxAoaPQEo6urEUalGqv7CIg5NA/Tpt0+RIivIiBFdPRF0vB uGGhgCeg81qQkzyEkCnb+S0kp6czieDowraB+wajJX9mDrQAgyK0e+KfdtlraO2v1416 a0evz26moHOj1y6xZyeQcX0cpIHN0K0eTUMTY/z53d86MrwQJ8By6p1eCAdm9Q/FFtgc iFiDir67p08Lodk88IzmcaWtYm3AJ5HQ+MR034idH0Ewe84/T2BCEHDG8HDZXP48Giwj t34WnP0gMktjXva5MxlQEgJXBddiPfkdh9GcpTmu8qv7/JidYCJcUjZ4REzSpbswhJug 8DtA== X-Gm-Message-State: APjAAAXZYTq/ONaHgFZ54hkZCX+mWssvV1BlU09VK2j6nHzhNO5TeziN DtsA6dQDgfw/4HT7xdPR5aPMUnyjisJ1VWMcDH36Qw== X-Google-Smtp-Source: APXvYqxwEL38tMqSon75QDc5FUVLaiP9P0qz5iqGeHpiTMMLzmmVT1f6O+M5fKVt9PA2/NoqtPiovv15q+//w2rZHLE= X-Received: by 2002:a92:8912:: with SMTP id n18mr6762042ild.241.1575512404899; Wed, 04 Dec 2019 18:20:04 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: From: Lorenzo Colitti Date: Thu, 5 Dec 2019 11:19:52 +0900 Message-ID: To: Mark Smith Cc: Lorenzo Colitti , v6ops list Content-Type: multipart/alternative; boundary="0000000000003c29c20598eb914c" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:20:08 -0000 --0000000000003c29c20598eb914c Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 9:53 AM Mark Smith wrote: > If hosts only acquired IPv4 addresses via DHCPv4 based on when the first > IPv4 application started running, then when a host is only running IPv6 > only applications, it would never acquire an IPv4 address because it > wouldn't need one, meaning never try to use DHCPv4 (so would avoid the > link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer > broadcast ARP Requests). > Speaking as an OS implementer: how do I know whether an application is an IPv4 application? - When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do that. - When it creates an IPv4 socket? But what if it's creating an IPv4 socket for the purpose of connecting to another network on the system (e.g., cellular data) that does have IPv4? - When it does a connect() on an IPv4 socket? But what if that's just a happy eyeballs stack that is using IPv4 because it might be available? - What if the app knows it needs IPv4 and will refuse to do any networking if it doesn't find an IPv4 address on the system? --0000000000003c29c20598eb914c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 9:53 AM Mark Smith= <markzzzsmith@gmail.com&g= t; wrote:
If hosts only = acquired IPv4 addresses via DHCPv4 based on when the first IPv4 application= started running, then when a host is only running IPv6 only applications, = it would never acquire an IPv4 address because it wouldn't need one, me= aning never try to use DHCPv4 (so would avoid the link-layer broadcast DHCP= _DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requests).=C2= =A0

Speaking as an OS= implementer:=C2=A0how do I know whether an application is an IPv4 applicat= ion?
  • When it calls getaddrinfo() with AF_UNSPEC? Pretty m= uch all apps do that.
  • When it creates an IPv4 socket? But what if i= t's creating an IPv4 socket for the purpose of connecting to another ne= twork on the system (e.g., cellular data) that does have IPv4?
  • When= it does a connect() on an IPv4 socket? But what if that's just a happy= eyeballs stack that is using IPv4 because it might be available?
  • W= hat if the app knows it needs IPv4 and will refuse to do any networking if = it doesn't find an IPv4 address on the system?
--0000000000003c29c20598eb914c-- From nobody Wed Dec 4 18:26:57 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5407120133; Wed, 4 Dec 2019 18:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bsl64A4bCrc; Wed, 4 Dec 2019 18:26:49 -0800 (PST) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C832120043; Wed, 4 Dec 2019 18:26:49 -0800 (PST) Received: by mail-ot1-x342.google.com with SMTP id a15so1287935otf.1; Wed, 04 Dec 2019 18:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSv4XAyI0p2jF7RcS6uHOC+0GT6hPqBupnoPwFakblw=; b=qxTAGozB45cjMocOlUH+71fo23ZvbaHZUkxsTwvquMJ5gNjvSgRh9UFaYDd1rk4j0h TlT5LtUtNtWDe8fF5loYXB5PizfQJcmQLZ5vzFtp9b7tKDZKNlb/rf3BONVp1LA5wQwb kwDYiRz3zC4E+fif8VFpbXoOey9IlDLt0IcT4Ksq21AjGEMy03ROuu5gEzYFEiQwVzRz Sf9nF7pSuUVvVz+RVeRQ7+0Yv53eAOlhBn2byvqoO7ZE2V1skR12Qv3HnhKg922DDdfK AvJI9itd/w/cq/y2vx2oeWiuBiTK97BpVh0mjxp/PGXl0f6AXxG6ve/wR7jL+7sC9PM3 JXyQ== 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=cSv4XAyI0p2jF7RcS6uHOC+0GT6hPqBupnoPwFakblw=; b=eSQDHkLI0MuKBuPhR3OxnG7fM2TA1grk9NlG92hraj2kAA8zZ16Bo7AFjI5O2ROgJ0 TFJ5bIWTE5byknTsxgE+dQ4Nx+6aWKwPaxCte1p5XqKAZ/Eg4FjUU9/sr79HqT6Gx9qu 6LEZeUBFY8qL81RqN+UvtuBTcIZEZShPjR8h0lMFuk37O69/RVotaSJtHDvcXhfjEY0N C6Loh49ktJZqvRGdMQNYKm12jGn5hBD0UsZ391BYuU2w3mGw44/sZ7jTtcmkHkpNeJLA cS1MPFZjG/T2FSFj929u0PUoOcY5vLRH1DfoRlGoJ08la70VU2HVlDgF2mzvSIYg/Amg 1ZSQ== X-Gm-Message-State: APjAAAWJ7+qQ5Kayj2bDuD510xmdvCYKR5Fv5ZY/cSH6qWzuhpGzecy/ cGo1amFmNpNrSzQgV4rJPisT+0kBE9PTJ0u0xlo= X-Google-Smtp-Source: APXvYqzEHLHlOYDShwnYZup7tavd+G07RkH64x4yD0BRN6MT3wH2wzFVfxuRO9FnZfCDqJJP+U/SRgIg+YM4TYBduIo= X-Received: by 2002:a9d:6005:: with SMTP id h5mr5299842otj.153.1575512808839; Wed, 04 Dec 2019 18:26:48 -0800 (PST) MIME-Version: 1.0 References: <6f8f4dbc-2f61-3aa9-16e9-cc6e6b11d246@marples.name> In-Reply-To: <6f8f4dbc-2f61-3aa9-16e9-cc6e6b11d246@marples.name> From: Mark Smith Date: Thu, 5 Dec 2019 13:26:22 +1100 Message-ID: To: Roy Marples Cc: dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:26:51 -0000 On Thu, 5 Dec 2019 at 12:37, Roy Marples wrote: > > On 05/12/2019 01:19, Mark Smith wrote: > > Going by the now almost entire lack of existence of Appletalk, IPX, > > DECNET, XNS, VINES (I haven't seen or heard of any of them in a > > network since 1999), it's likely IPv6 will be the single network > > layer protocol in the future. Running a single network layer protocol > > is cheaper and easier, which is why those others have gone away (that > > also explains why nearly all links use or emulate (Wifi) Ethernet > > framing, unless they specifically can't). > > > > IPv6 will have a life, just as IPv4 has had a life, and those other > > past protocols have had a lives. IPv6 is designed to last for much > > longer than almost any of them, centuries most likely, so I don't > > think we shouldn't be worrying about accommodating "IPv8" now at the > > cost of making IPv4 easier to move away from. We don't have any idea > > what "IPv8"'s transition requirements are or what it will even look > > like. > > And this affects the wording and intent of my proposal how? > I wasn't addressing your specific proposal. I was addressing this comment. "> It assumes that IPv6 is the be-all and end-all. Maybe one day we will > have IPv8?" and indirectly this comment: > BUT - what if we need to enable DHCP again? Should clients still listen > for FORCERENEW? It does pose a small dilema because there isn't actually > anything to renew." A network/link using the sort of mechanism in this draft and the past IPv6-Only RA flag draft have made conscious decision to switch off IPv4. They have actively decided that "IPv6 is the be-all and end-all" is their intent from now on. They know they're very unlikely to need to switch IPv4 back on on that link (otherwise, why would they enable these types of mechanisms?), which means we don't have to place much if any weight on situations such as "BUT - what if we need to enable DHCP again? Should clients still listen for FORCERENEW? " If somebody wanted to switch IPv4 back on on that link, after they've actively enabled one of these IPv4 switch off types of mechanisms, then it would be reasonable for us to assume they're willing to reboot all of the hosts or similar to boot strap DHCPv4 again. They they're not willing to go to that effort, then they're not ready to switch IPv4 off yet. > > 1 client sends DISCOVER with I CAN WORK WITHOUT DHCP ADDRESS option > 2 server sends I HAVE NO DHCP ADDRESS option with T2 timer > 3 client reads this and will retry in T2 seconds > > This satisfies the use case the OP put forward and makes no mention of > any other protocol than DHCP >AND makes things much simpler to actually > implement. > What did I miss? > > Roy From nobody Wed Dec 4 18:27:36 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04212091E for ; Wed, 4 Dec 2019 18:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRDFgko1AexO for ; Wed, 4 Dec 2019 18:27:34 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABE8120828 for ; Wed, 4 Dec 2019 18:27:34 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id d124so2018737qke.6 for ; Wed, 04 Dec 2019 18:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xkmWb9kwsFnEKUSavCJjZJHEN+Y4Wq4p702oe7qfDOU=; b=KKFVaUjeAmHWETZS8E/5vp++2Qkey67tUj0c11vdGnZJVhsroBti0gLJ4wA+35jjQw GVsFfMH/muarVEAjB/wquluPDz8lQKrosrqFyZ7nRdNDXoc+wUKh2x6RrFC4P9tH/lfF euP9Tfs3lAmwnbn3h3MvA2/yimpMsMaW9uH9hOqMzFet/1RCFLxBkH0v4Ap+qg4mDqoR uBimaYrRDaUoXZWhbYeS0VAEeOnszYYkMQ572nkMFn4xu+sQjil7908v69LVD/SaMtke 7czbGAP0VwkfuZjS/qoYgLlrS3Ewfi2+js+Q1U+rGVJsYoYw2gtBiML0eJh7vAjcKNX4 9/8Q== 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=xkmWb9kwsFnEKUSavCJjZJHEN+Y4Wq4p702oe7qfDOU=; b=ZjA5V7S7YO4x4oqFmw9ZOR/0FM03ZKdn/2e7ajtwOzk6dLU9ZdDtQvo4GJav7VjeJS PWrNauxZd4MVI4w3YrURA97dfGdzC6MFPh65PT//lMtz9tTnBKM/rqZngOaFgSvEejpt YN3ch+zoYohonz8/IvrAWIJs+qAs7zcx9rVhCpTTZBMV/n0IIKdmV4thzzBGepdHZNh5 ihdqORrTadvMRqemWQeN3jKeRd5cnh3L+YYUcIg9jSvTin0LfXAkUp1ESLdYK1ScemFT 5M/eVF8EPaD6MUfNDO1g0TQ0HUSQKG1uZOJ8UxNGDplq6RqhypigL9aU30+tT1KSPquG rr7g== X-Gm-Message-State: APjAAAUXAGtdIWpgH5bPpKiN19s5BaW/vp0W4Kf3h2XePnOlXSM/lXEW hV2Zt+7f29yWxeXhawzj62l4U+uinI5p0Mw+aLg= X-Google-Smtp-Source: APXvYqzp0FLwDzA52Ibxasd1v1Jcb+3WHk7A3YE13YAlcoevINGkqshY5/VL4YCGW/thIw8eb49agJlcVszDAhzA1b4= X-Received: by 2002:a37:4841:: with SMTP id v62mr5896621qka.444.1575512852716; Wed, 04 Dec 2019 18:27:32 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 13:27:21 +1100 Message-ID: To: Mark Smith Cc: Lorenzo Colitti , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:27:35 -0000 On Thu, Dec 5, 2019 at 11:53 AM Mark Smith wrote: > Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first application opens an IPv4 (or IPv6) socket, and then released when the last application closes the last IPv4 socket? - Because then all devices in my network would request IPv4 all the time. Even if an application supports IPv6, it might still try to open IPv4 socket. In case it's on a dual-stack or IPv4-only network. Therefore I'd not achieve my goal of reducing IPv4 footprint in the network. - If the host is running clat, then applications might open IPv4 sockets but it does not necessary mean the host itself needs an IPv4 address. It might not if the network provides NAT64. Or it might if the network is just dual-stack or IPv4-only. -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 18:27:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD371209A6 for ; Wed, 4 Dec 2019 18:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 a50IXw073Gg7 for ; Wed, 4 Dec 2019 18:27:49 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C7F1209D8 for ; Wed, 4 Dec 2019 18:27:49 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id a7so1574517ild.6 for ; Wed, 04 Dec 2019 18:27:48 -0800 (PST) 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=MBRgDa751wyOq9R/w0wrjhWX72oDu8VHxC/jKeVPGgw=; b=cC/sa/gymHUQ6DPyrcuP0DFTB7xawI1BRXoI8mY6P1QiDD42pIT8RXjBaXNuw/HcHl bSvNXgo6Cr12E0d1P2/uXAMK9iJjEb+kbof/l8UThZx3vlNAMaN3ewfZ9kbZo+0lUNxK WvkO9Fkfd2cAW5lahHCmfxNbk0fcd2ZAiN3I527GZSGI0kXZQKVXztVy9h5BCQ1Bnw6Z jFb/faL1Bcw2y6i7U+whW6jm3iO7InIsj4sk6smluEJToPtdkX4AaTsQM+tQ6XHScAHi DEZqX9G2anVX331WPHo4UFgNe4j0runXDsOHMXOhBxHfmmiUKuTjM7oY5ZK6gw7uBNqW OL2w== 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=MBRgDa751wyOq9R/w0wrjhWX72oDu8VHxC/jKeVPGgw=; b=C1IY09JE6SNO5U3qAV2rBT/+YTbTfhRUaKNaiq/+sMiXZUxd/H0dz91XtZfHsRZp4X Mk+XAh9nZEaBhLmzDc9RvPjvFbIzkX9GM4t0EqJTyQc/N5D3Il27fMr+O/Mw5uFHSIpp 6IrLLb/ARO1B6mRcD3uo5nBfPI11vXYXfiAnoWr4FdkbCLl4gW15KF8UmVa3ZC+uczV4 HM1UgElLiSNW/+gfzmwSGmYdCyf/5qt++9bRf2jEmmFWu8e0cnK4st3pskftPSupzq3o AizDUrInfihPSkTagm8kdqFJ83keLRhxd6GosM8UJ8P+WHUKPgymg8QGf97BtammggTq q75Q== X-Gm-Message-State: APjAAAUQK+nBbs6Lf0LnX66DlNscd14dOswuHdyakhiCyKSEOtsuKooU rsnp4g/52rW32vwO4nmb4c0VVSFp7ghCeMclkmpk2g== X-Google-Smtp-Source: APXvYqyZ0QNee4RyDPVACo2yPpz4s66MNcFv1grKP5Ldjw6pqsomPDWpeSLPWeGuZvnxXqvM42uNTHpqToOmoctTJCs= X-Received: by 2002:a92:3b10:: with SMTP id i16mr7107627ila.170.1575512868096; Wed, 04 Dec 2019 18:27:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Thu, 5 Dec 2019 11:27:36 +0900 Message-ID: To: Roy Marples Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000d800d70598ebac1b" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:27:53 -0000 --000000000000d800d70598ebac1b Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 10:12 AM Roy Marples wrote: > > The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT > seconds. > > Is the wait seconds even needed? > Just set the T2 timer and treat it as leasing the unspecified address. > Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides > nothing of value as I see it. > I think there is value because the two are conceptually different. The T2 timer is about the validity of the address that is offered, and specifies how often that address should be renewed if the client accepts the offer. The V6ONLY_WAIT timer is about how long the client should wait before asking again if it doesn't accept the offer. I think these two could be very different. For example, if IPv4 is a very scarce resource and almost al clients are IPv6, the operator will want to use short lease times (e.g., 1 hour, or shorter) to ensure that hosts that disconnect from the network don't tie up scarce IPv4 addresses when they're not connected. That same operator would want the V6ONLY_WAIT timer to be large in order to avoid excessive load on the DHCP server (and to conserve battery on the devices). If there is consensus that this is useless we can remove it, but I don't see a a strong reason to give up that extra flexibility. Is there? --000000000000d800d70598ebac1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 10:12 AM Roy Marpl= es <roy@marples.name> wrote:<= br>
> The draft covers that scenario. DHCPv4 is disabled for V6ON= LY_WAIT seconds.

Is the wait seconds even needed?
Just set the T2 timer and treat it as leasing the unspecified address.
Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides nothing of value as I see it.

I think t= here is value because the two are conceptually different.

The T2 timer is about the validity of the address that is offered, = and specifies how often that address should be renewed if the client accept= s the offer. The V6ONLY_WAIT timer is about how long the client should wait= before asking again if it doesn't accept the offer. I think these two = could be very different. For example, if IPv4 is a very scarce resource and= almost al clients are IPv6, the operator will want to use short lease time= s (e.g., 1 hour, or shorter) to ensure that hosts=C2=A0that disconnect=C2= =A0from the network don't tie up scarce IPv4 addresses when they're= not connected. That same operator would want the V6ONLY_WAIT timer to be l= arge in order to avoid excessive load on the DHCP server (and to conserve b= attery on the devices).

If there is consensus that= this is useless we can remove it, but I don't see a a strong reason to= give up that extra flexibility. Is there?
--000000000000d800d70598ebac1b-- From nobody Wed Dec 4 18:29:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538712018B for ; Wed, 4 Dec 2019 18:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 6rpNre02bodh for ; Wed, 4 Dec 2019 18:29:24 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F838120043 for ; Wed, 4 Dec 2019 18:29:24 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id b15so1607868iln.3 for ; Wed, 04 Dec 2019 18:29:24 -0800 (PST) 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=Y2YzOz2V6SLmd+i8TZEW6BbKaIhc+H7M+dW0QUgw3Vg=; b=R+gyNDSlIpDHz4uCZuWeOKuwkjqa56AKHzWTiQZ/FzwhyKnHlLNFRjlLHMfTN4OwAq E7cszQ2h/T+/NXjxfWCkXxXprCMc9RVqoZinVw9DNfmp4DwQ1t5Xowco7MXVgRKfvoWR neZsmRPqfTIMlqVmijReLLkZ4LLutWEwBNnkMxBcshujYz8xBiWQY9h7BFMLm0XSZBFj vsQFeoOh+zBvfHZpXgmNOkCYgoDPt/1UqLEBzd5m4BySCM965BUUWkBuhq22kqrPfn42 Kt669GwEElAJDiy6byk5SeraRtedIYGBlCdEvMwT9+IS62RCIuZ/u5etuBvfOuepVCFB 8RjA== 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=Y2YzOz2V6SLmd+i8TZEW6BbKaIhc+H7M+dW0QUgw3Vg=; b=frC7mkLLeUNPhLghrN09eDvNV6k5sMOeVOkZ9PXjZ5UabPg148P94rCKB9rfqqkBcF 4R3o3mCN+iOkA5JE7HZ82kXeWKpguO7KoCy5LxB4dc0dfSlPAvP25w7CpImUH+dzMuxB +OpBW6YpT8+xlA3nvoyO0vm8NnXLmwP1YAabNk5EBWYEktb9yM/e5HEStWXkCbnUyxLE SfdMb/k0orgB8P9Heu2FtfnxyibW+vI7eZpenJVFaDWjN+DamTqCFzczvSFcaST/kLyZ JsBC/hmoKev9wiZ8vKFsWA9HolgbioTDIpmDeLteXUgumUu4/QVOMRzhWoTQCeB6aYp/ /2sQ== X-Gm-Message-State: APjAAAUJgDAYwTFWpbXvqH68bogaJfKTNfATMUbWWNv6p7FoED1MQ2Ys lf3UyD6FpSfJXCBNMNdZ/831whYbnqlVrzkZSl4EiQ== X-Google-Smtp-Source: APXvYqzdQ3rmSSwK3VP7vYhcp7Y4UnSmLIVahl1IgviZ2zdB9Rimuod084NcEW+cz9Z8hY3bbg0aNpVDyySPXFkt6zM= X-Received: by 2002:a92:ba93:: with SMTP id t19mr7109382ill.0.1575512963545; Wed, 04 Dec 2019 18:29:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Thu, 5 Dec 2019 11:29:11 +0900 Message-ID: To: Roy Marples Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000886a810598ebb2f4" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:29:26 -0000 --000000000000886a810598ebb2f4 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 11:27 AM Lorenzo Colitti wrote: > specifies how often that address should be renewed if the client accepts > the offer > Ok, not renewed, rebound. But I think the point still stands. --000000000000886a810598ebb2f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 11:27 AM Lorenzo C= olitti <lorenzo@google.com>= wrote:
specifies how often th= at address should be renewed if the client accepts the offer

Ok, not renewed, rebound. But I think the poi= nt still stands.=C2=A0
--000000000000886a810598ebb2f4-- From nobody Wed Dec 4 18:50:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31870120133 for ; Wed, 4 Dec 2019 18:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDzIGEQjkn96 for ; Wed, 4 Dec 2019 18:50:36 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB66412018B for ; Wed, 4 Dec 2019 18:50:35 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 47790795 for ; Thu, 5 Dec 2019 02:50:32 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 685CA1CD619; Thu, 5 Dec 2019 02:49:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575514175; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S8GN9mZK9baFOn3SWg89BELnYS6umCf4KSKd5kVRCPg=; b=DAseBfvkccssJEyRxq/Fyhm4hr96WfDJcaZFTRNq+BICbTWB50C2akdtL+YuCoK+l15fYi hL6+yylAKbYAbN3WQgCRICKKlPWmecVsC9ux5Zsh2YX/gIvX/++pIjIfN1a4PiP5HeU9NK nTdD9u9SuAoGyXNkXhyf2YbEPFdVwDk= To: Lorenzo Colitti Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List References: From: Roy Marples Message-ID: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> Date: Thu, 5 Dec 2019 02:50:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 02:50:38 -0000 On 05/12/2019 02:27, Lorenzo Colitti wrote: > On Thu, Dec 5, 2019 at 10:12 AM Roy Marples > wrote: > > > The draft covers that scenario. DHCPv4 is disabled for > V6ONLY_WAIT seconds. > > Is the wait seconds even needed? > Just set the T2 timer and treat it as leasing the unspecified address. > Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides > nothing of value as I see it. > > > I think there is value because the two are conceptually different. > > The T2 timer is about the validity of the address that is offered Wrong. The T2 timer addresses the lease as a whole. At this point the address is just meta data, just like domain or dns servers. , and > specifies how often that address should be renewed if the client accepts > the offer. The V6ONLY_WAIT timer is about how long the client should > wait before asking again if it doesn't accept the offer. Wrong again. Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP should not depend on any IPv6 settings - or vice versa. Is it too much to ask to keep protocol setup separate? As we're not offering an address in this situation, how is V6ONLY_WAIT different from a timer source that cannot exist? As such, why invent a new timer source? > I think these > two could be very different. For example, if IPv4 is a very scarce > resource and almost al clients are IPv6, the operator will want to use > short lease times (e.g., 1 hour, or shorter) to ensure that hosts that > disconnect from the network don't tie up scarce IPv4 addresses when > they're not connected. That same operator would want the V6ONLY_WAIT > timer to be large in order to avoid excessive load on the DHCP server > (and to conserve battery on the devices). > > If there is consensus that this is useless we can remove it, but I don't > see a a strong reason to give up that extra flexibility. Is there? I don't see any extra flexibility offered. You talk about lease times and yet say T1/T2 can't be used - why? All I see is more complication when things can be kept simple. Roy From nobody Wed Dec 4 19:48:27 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8074120802 for ; Wed, 4 Dec 2019 19:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 aQ4W0f3r3Q65 for ; Wed, 4 Dec 2019 19:48:23 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B4E12001A for ; Wed, 4 Dec 2019 19:48:23 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id z23so2058199iog.11 for ; Wed, 04 Dec 2019 19:48:23 -0800 (PST) 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=e4ts32lkOaN+Ut/sOdwmF5VA+F89vTh8XGY7eWNOw+k=; b=oD9yuGxEb9L4rhh0B0wRG2ahCRIY4CJ6QmIFT6afvUsh0wuDrdq01pLyIJceGJuXtq 1N+5JOCtaDfEyRaNP7mIIvGEti8kcj4N08uYEbADqtAVBnunnbtf9CN0qGp7W3+KAydA QAowEbQpfT9zGuq2taigXy2ksD4PkdEMOb4RbL97AZahIW6fcicvV/rXemsPnvZsxQ+L ahnwKUv0w3I9NKmzrrWMt8yfvbBIx66jlMi6PmJKLu0F8wAKuBndFqNENNPMhlw/nd1n vI+QpTNpzMZvUtOR35i9SCbAg5OvmVPyhqUBTHGQu1X6qrG049m+d/Pq72pG5TKy+gyp nOag== 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=e4ts32lkOaN+Ut/sOdwmF5VA+F89vTh8XGY7eWNOw+k=; b=IK6A8VZT92yf9oAsXUj7ZWj80K9A1k4snrqTP9KdwOrHhmVnRozueUvy632BFB2G7d AeiwCIlux53yC+mv43uiqxWDLuSPgPqv+7l/wWMALnvLaGJsxgqTnULqHH7WHu5fyxlp H69Ns7wVtcOZY12F8qGv3EF29ivZPZCRcVYJYbEY0XTigshigB/AWD9hacPivRNRJ31q rJCu6nqyYJLpjlJna0cobW6OXnjgzcaag3MWVur+Vu0+AMgqYSXZUaHVe/mkED8sTf8q fBfY9I6W4okBxIDV2AytCxcWbVP/tZnQBTPi6sOZDjQajBB8L2HhW0/QNHqgX3BzfIX2 Nahg== X-Gm-Message-State: APjAAAVj7pfQwXixVb7kJjUNB5CCylGWYg8f5TBfwTEX4SrD1po6MUZf 1R0OkuUnokgvmR//TRkcJkqPH/7Xe7tiwzfn6ciTng== X-Google-Smtp-Source: APXvYqyWeV8Itr9HANOoiyEpz26siqZyTb7HFlcjxT6aZKvZjCbXZxtVg0WMHG24oWwpE2brpKe20yzKrPl2UMk1VVo= X-Received: by 2002:a02:9203:: with SMTP id x3mr6204110jag.62.1575517702323; Wed, 04 Dec 2019 19:48:22 -0800 (PST) MIME-Version: 1.0 References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> In-Reply-To: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 12:48:10 +0900 Message-ID: To: Roy Marples , Tomek Mrugalski Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000fc80570598eccc8f" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 03:48:26 -0000 --000000000000fc80570598eccc8f Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 11:50 AM Roy Marples wrote: > > The T2 timer is about the validity of the address that is offered > > Wrong. > The T2 timer addresses the lease as a whole. At this point the address > is just meta data, just like domain or dns servers. > Regardless: the T2 timer is about the validity of the information that is offered. The V6ONLY_WAIT timer is different: it's about when the client should ask again if the client *does not request* the offer. Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP > should not depend on any IPv6 settings - or vice versa. Is it too much > to ask to keep protocol setup separate? > Then suggest a name that you like more? I can think of DISCOVER_WAIT and INIT_WAIT, but I'm fine with any name that has WG consensus. As we're not offering an address in this situation, how is V6ONLY_WAIT > different from a timer source that cannot exist? As such, why invent a > new timer source? > In the document as currently worded, the network does offer an address. It says that the client MUST NOT configure the address if it supports the new option. > > If there is consensus that this is useless we can remove it, but I don't > > see a a strong reason to give up that extra flexibility. Is there? > > I don't see any extra flexibility offered. You talk about lease times > and yet say T1/T2 can't be used - why? All I see is more complication > when things can be kept simple. > There's a difference in semantics: the least time is meaningful to clients that request the lease and directly affects their behaviour and the number and frequency of DHCP packets that they send. The V6ONLY_WAIT timer is meaningful to clients that do not request the lease. As in the example I provided, the operator is likely going to want to configure them differently. We should also bear in mind that there may be devices on the path (e.g., relays, snooping switches) that see these offer packets. Using a separate timer avoids the possibility that these devices would act on the T2 field in ways that we don't anticipate or desire. Using a separate option also makes it clear that there is no need for this document to update RFC 2132 and RFC 8415 to amend the definition of the IP address lease time option and the T1/T2 timers. >From a complexity perspective, I think a separate timer is actually simpler. While it does need to be parsed, that needs to happen anyway. The fact that it's a separate option and has separate semantics makes it easier to reason about the behaviour of the state machine than if we were overloading the existing option. As the maintainer of a popular DHCP client myself, I would prefer it. Additionally, I would expect that a separate option would be simpler to implement on the server side. This is because the server can just continue to consider the lease time a property of the address pool, and treat this new option simply as a statically-configured option that is returned to clients iff they requested it in the PRL. If we use the same field for the lease timer and the V6ONLY_WAIT timer, then the server will need to change the lease timer in DHCPOFFER packets depending on whether the option was requested or not, and I would expect that to be more complex. +Tomek Mrugalski any thoughts on this? --000000000000fc80570598eccc8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 11:50 AM Roy Marpl= es <roy@marples.na= me> wrote:
> The T2 timer is about the validity of the= address that is offered

Wrong.
The T2 timer addresses the lease as a whole. At this point the address
is just meta data, just like domain or dns servers.
Regardless: the T2 timer is about the validity of the informat= ion that is offered. The V6ONLY_WAIT timer is different: it's about whe= n the client should ask again if the client *does not request* the offer.

Or at = least V6ONLY_WAIT is at the very least badly worded, but DHCP
should not depend on any IPv6 settings - or vice versa. Is it too much
to ask to keep protocol setup separate?

Then suggest a name that you like more? I can think of DISCOVER_WAIT and I= NIT_WAIT, but I'm fine with any name that has WG consensus.
<= br>
As we're not= offering an address in this situation, how is V6ONLY_WAIT
different from a timer source that cannot exist? As such, why invent a
new timer source?

In the document as cu= rrently worded, the network does offer an address. It says that the client = MUST NOT configure the address if it supports the new option.
=C2= =A0
> If there is= consensus that this is useless we can remove it, but I don't
> see a a strong reason to give up that extra flexibility. Is there?

I don't see any extra flexibility offered. You talk about lease times <= br> and yet say T1/T2 can't be used - why? All I see is more complication <= br> when things can be kept simple.

There&#= 39;s a difference in semantics: the least time is meaningful to clients tha= t request the lease and directly affects their behaviour and the number and= frequency of DHCP packets that they send. The V6ONLY_WAIT timer is meaning= ful to clients that do not request the lease. As in the example I provided,= the operator is likely going to want to configure them differently. We sho= uld also bear in mind that there may be devices on the path (e.g., relays, = snooping switches) that see these offer packets. Using a separate timer avo= ids the possibility that these devices would act on the T2 field in ways th= at we don't anticipate or desire. Using a separate option also makes it= clear that there is no need for this document to update RFC 2132 and RFC 8= 415 to amend the definition of the IP address lease time option and the T1/= T2 timers.

From a complexity perspective, I think = a separate timer is actually simpler. While it does need to be parsed, that= needs to happen anyway. The fact that it's a separate option and has s= eparate semantics makes it easier to reason about the behaviour of the stat= e machine than if we were overloading the existing option. As the maintaine= r of a popular DHCP client myself, I would prefer it.

<= div>Additionally, I would expect that a separate option would be simpler to= implement on the server side. This is because the server can just continue= to consider the lease time a property of the address pool, and treat this = new option simply as a statically-configured option that is returned to cli= ents iff they requested it in the PRL. If we use the same field for the lea= se timer and the V6ONLY_WAIT timer, then the server will need to change the= lease timer in DHCPOFFER packets depending on whether the option was reque= sted or not, and I would expect that to be more complex.=C2=A0+Tomek M= rugalski=C2=A0any thoughts on this?
--000000000000fc80570598eccc8f-- From nobody Wed Dec 4 20:46:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828F412095A for ; Wed, 4 Dec 2019 20:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h75EcBJtxwzM for ; Wed, 4 Dec 2019 20:46:05 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C511200B4 for ; Wed, 4 Dec 2019 20:46:05 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 8A90179B for ; Thu, 5 Dec 2019 04:46:03 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id B9FF11CD619; Thu, 5 Dec 2019 04:45:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575521105; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ui3n6UqhQE17L5sJ7Y8kxrRRq7NnUSLUslE28hdfGfc=; b=E5clX5kmJaU64+OQ1r8pdUydHKzc7kPYLQAkS8DmLsIGjCCqhzYA0dbdzfTA4zFE9n0qbr psnloJIEUCw07dfNnUPzngCLuTJ6rC488icvG5TtWy8Z0azZCu/7dqlgy/4lkB6+lqYGLd p5PyLWE4QIRO1/aI8Lu/a9ZWE+lieV8= To: Lorenzo Colitti , Tomek Mrugalski Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 04:45:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 04:46:07 -0000 On 05/12/2019 03:48, Lorenzo Colitti wrote: > On Thu, Dec 5, 2019 at 11:50 AM Roy Marples > wrote: > > > The T2 timer is about the validity of the address that is offered > > Wrong. > The T2 timer addresses the lease as a whole. At this point the address > is just meta data, just like domain or dns servers. > > > Regardless: the T2 timer is about the validity of the information that > is offered. The V6ONLY_WAIT timer is different: it's about when the > client should ask again if the client *does not request* the offer. So in simple terms. The server offers some information. Given this information (in current DHCP semantics) we can RENEW (T1) or REBIND (T2). If the client does not request the offer (hey! I see this new fangled option here that says NO DHCP) the client can still accept the T2 timer at the very least. Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new timers. > Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP > should not depend on any IPv6 settings - or vice versa. Is it too much > to ask to keep protocol setup separate? > > > Then suggest a name that you like more? I can think of DISCOVER_WAIT and > INIT_WAIT, but I'm fine with any name that has WG consensus. > > As we're not offering an address in this situation, how is V6ONLY_WAIT > different from a timer source that cannot exist? As such, why invent a > new timer source? > > > In the document as currently worded, the network does offer an address. > It says that the client MUST NOT configure the address if it supports > the new option. You are directly correlating T2 to an address. Please don't - T2 is for the whole lease. > > > If there is consensus that this is useless we can remove it, but > I don't > > see a a strong reason to give up that extra flexibility. Is there? > > I don't see any extra flexibility offered. You talk about lease times > and yet say T1/T2 can't be used - why? All I see is more complication > when things can be kept simple. > > > There's a difference in semantics: the least time is meaningful to > clients that request the lease and directly affects their behaviour and > the number and frequency of DHCP packets that they send. The V6ONLY_WAIT > timer is meaningful to clients that do not request the lease. I'm not fully following here. DISOVER - DHCP optional server says - OK, retry around T2 (our new option) vs DISCOVER - No new option, I want a lease server says - Sure! here's T1 and T2 timers As in the > example I provided, the operator is likely going to want to configure > them differently. We should also bear in mind that there may be devices > on the path (e.g., relays, snooping switches) that see these offer > packets. Using a separate timer avoids the possibility that these > devices would act on the T2 field in ways that we don't anticipate or > desire. Using a separate option also makes it clear that there is no > need for this document to update RFC 2132 and RFC 8415 to amend the > definition of the IP address lease time option and the T1/T2 timers. > > From a complexity perspective, I think a separate timer is actually > simpler. While it does need to be parsed, that needs to happen anyway. Only because you are insistent in putting it into a new option. It's not needed. > The fact that it's a separate option and has separate semantics makes it > easier to reason about the behaviour of the state machine than if we > were overloading the existing option. As the maintainer of a popular > DHCP client myself, I would prefer it. Well, if you prefer extra code, unit tests and bloat, don't let me stop you. But when it comes to my code I would rather keep it lean and mean. Or to put it another way - I would not like anyone to force needless code when it's not really needed. > Additionally, I would expect that a separate option would be simpler to > implement on the server side. This is because the server can just > continue to consider the lease time a property of the address pool, and > treat this new option simply as a statically-configured option that is > returned to clients iff they requested it in the PRL. If we use the same > field for the lease timer and the V6ONLY_WAIT timer, then the server > will need to change the lease timer in DHCPOFFER packets depending on > whether the option was requested or not, and I would expect that to be > more complex. +Tomek Mrugalski  any > thoughts on this? From what I'm proposing, the extra option server side is like DHCP:on/off It's not complex or rocket science. It addreses the need. There is no concern about IPv6 or future IPv8 or whatever. Roy From nobody Wed Dec 4 21:33:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385651200BA for ; Wed, 4 Dec 2019 21:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC9Qolz8zj5u for ; Wed, 4 Dec 2019 21:33:03 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD17120047 for ; Wed, 4 Dec 2019 21:33:02 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id m188so2333079qkc.4 for ; Wed, 04 Dec 2019 21:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wB2Q/Riq2sBx7NcHZpBGSiDw9/LBWOVvnH2FlyfA5t0=; b=NlTOaryXJzF5mBZwSJewfOfmC04uKvFuIFBWqdrnQnkPG1AoaARS28bPoUUdTxRW8R 9cA6YIuxN6X8hxpMrGgmPthzT/pLDt3zBZMVjErAC8/68gfwa7ynnh52jxUfzkQWOTN9 q9IY+wFN/dGmIMlP37ZLlYOPepQNvYvXO368DhF/GR3V0TZltg3jmcBuieUGyVvknalN pgDEdzgWSP6AHazs30vMfNHJt5uYocMcXW0D9LyYuuRk9JSnRS+nB6QMGLPc5U9V/HNr j80r5LhR0axVvspJReLrUkV5ye5ItsMQcqJYUtVKePFOPZaZm2Of+HgFziBKl2Evr1Yb 2KkA== 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=wB2Q/Riq2sBx7NcHZpBGSiDw9/LBWOVvnH2FlyfA5t0=; b=TfnjnQZGCgXg3z82tW9m5vmjnRS754DqV4KzWHR7GmhjbyqoroPYo4d8yHIMU6hncn JgGdgpALKOVZ6Ch2A3OPehDv8QBBFafsbVORTSKQRUx02SM75LmGeWX9p+1eSOi0QR/g hS6aAjr2yli4PWEHPkRiYf/2l1QIIZ4NIOiukZLSCGE4RhR6Jtz1V4XfYVXZxYchQbyC tj3oHTIZ4kQdozu5Kcqx53ZXMAdKTCM+VE06gGURSmd/PT2cyzCTH5dgxAgOggel3jn+ u312mgTrDTb7jWbUymrzOFxGTPZu6R1WIvCnYRbEejBvrtFTtoYa/AyM4x/3hqX6lr3c 7jGw== X-Gm-Message-State: APjAAAXFUn3akySVN2JwbrepPFjuCx+jwQ29kwzt7V14FNgokJ/SMPIy JlclPwoF1dNTVGOIhAuXshei8yO46qlxDEReLyJFLotn X-Google-Smtp-Source: APXvYqzVWkmintQ4+KPKGI1UXbF38gNdQpqnl7rkSX5ueIhorP7H46hpPcpa0MJi5f81TBND4VOIloupBhn9hCKdL6U= X-Received: by 2002:a37:7686:: with SMTP id r128mr5640384qkc.277.1575523981805; Wed, 04 Dec 2019 21:33:01 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <7b646344-d0b7-ee6e-d732-4e10898b61e3@si6networks.com> In-Reply-To: <7b646344-d0b7-ee6e-d732-4e10898b61e3@si6networks.com> From: Jen Linkova Date: Thu, 5 Dec 2019 16:32:50 +1100 Message-ID: To: Fernando Gont Cc: Brian E Carpenter , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 05:33:04 -0000 On Thu, Dec 5, 2019 at 9:20 AM Fernando Gont wrote:> > Disclaimer: I haven't red the document. > > But based on your description, I would suggest that the subject line is > changed. And that if there's similar wording in the document, that's > changed, too. > > An DHCPv4 option to turn off IPv4 is acceptable (the two protocols are > *npt* being entangled). Whereas the subject line makes one thing that > you are using IPv4 to convey IPv6 signals -- where in fact you seem to > be using IPv4 to signal information about IPv4. What exactly is negotiated using the proposed mechanism is "*if* the network provides NAT64 service, the host does not need an IPv4 address". -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 21:52:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115061200BA for ; Wed, 4 Dec 2019 21:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 I-7RsiQ6sgpL for ; Wed, 4 Dec 2019 21:52:14 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E72120047 for ; Wed, 4 Dec 2019 21:52:13 -0800 (PST) Received: from [192.168.4.77] (unknown [190.179.35.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9A0C6855F2; Thu, 5 Dec 2019 06:52:10 +0100 (CET) To: Jen Linkova Cc: Brian E Carpenter , V6 Ops List References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <7b646344-d0b7-ee6e-d732-4e10898b61e3@si6networks.com> From: Fernando Gont Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <9a80258d-f001-3be5-96fe-c416ad50bde2@si6networks.com> Date: Thu, 5 Dec 2019 02:51:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 05:52:16 -0000 On 5/12/19 02:32, Jen Linkova wrote: > On Thu, Dec 5, 2019 at 9:20 AM Fernando Gont wrote:> >> Disclaimer: I haven't red the document. >> >> But based on your description, I would suggest that the subject line is >> changed. And that if there's similar wording in the document, that's >> changed, too. >> >> An DHCPv4 option to turn off IPv4 is acceptable (the two protocols are >> *npt* being entangled). Whereas the subject line makes one thing that >> you are using IPv4 to convey IPv6 signals -- where in fact you seem to >> be using IPv4 to signal information about IPv4. > > What exactly is negotiated using the proposed mechanism is "*if* the > network provides NAT64 service, the host does not need an IPv4 > address". Let me rephrase my question. What are the semantics of the option? "Turn off IPv4?" -- If that's the semantics, then what triggered the use of the option, from the pov of the ipv4 host, is rather irrelevant. Side question: What if the network provides NAT64 service, but there are local nodes that do not implement IPv6 (e.g., printers)? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 4 22:34:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C091200CE for ; Wed, 4 Dec 2019 22:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 G3Wl6SHmukI4 for ; Wed, 4 Dec 2019 22:34:15 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1D81200B6 for ; Wed, 4 Dec 2019 22:34:15 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id z193so2464383iof.1 for ; Wed, 04 Dec 2019 22:34:15 -0800 (PST) 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=LLL3Kw/vQbBRclfRW5XwYwYxUxlPGcZoHheknUsBjMg=; b=SziW1rn4qfG2inCfOrlhRrH6xav0rf4xhs4TIVQBHIqr5er3rhcaAsVbio/CIrM/GM 6z98tv1vsP+wmGBVMpStofNa2LAYGtQy9uzkDPk8dog0xeWze+jYy1iZmf17WXQKv03l g0I4Axz8aN94FmPB6nT5iafZvBryyhkmjqJc7DmjSP1/xRxLXHStyvmWaCySPWDN2BNu cSSte8DJDOFiK3iGOzOA4WVMUuxNWfUf37QbslchkajlfEmDFn076HaETPv8qEgdBXv0 vhJm/7cDeAOvMX6WtyFz2VovclOgMqK1CcFwL3CZA4dZoUWxPvu8qVjB+xfilhs/VcNB ykVA== 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=LLL3Kw/vQbBRclfRW5XwYwYxUxlPGcZoHheknUsBjMg=; b=Qht+RciN6gx7iYQIlv1k8o1QLkqB/tvOjx4ZqypBNbWpyQM+OWEWHvAu8KcPTDbBeS 54GSmdeyThjLrk/AJ/f3sJA7aoKxSgHG9bU8RYDpUEjG2YAxnNi1gdNpAIRnCTu3cMWT cOKa+nz8GJENprSxVVi24kDt2nTYaFrlkMKs/b0P+tkGVH+3GJaCtrTmAkeuPXEd5i2Q nq1B7rq7eLj4b0YC74sLVBl4YYoAd6mch2j0mAL0DW99wcknj7+J7/5ybSPWIcx1hX2z kcKIhpYyERFpe+I0vN2p4kA82VSnLMHclzdEpxzaPS+qHaelI1xMM9VRlWtESgqmU6PQ 4HjQ== X-Gm-Message-State: APjAAAW5sBZitPTlYuiWo5Q3OOqoIPKb51jVulHj0E8Rz14YrP4txVIW BEzsgUbS226uw/Fec2mGDUxY+3VspyXnbuh1IcRIZw== X-Google-Smtp-Source: APXvYqzEKC0Pjukui6Sp6wxcX29Xv040tJ5xgVMcVhWL0Wnvwes5dZjfa0gYyxi4V8Y6o9IXokxzt+B8yHXKjtmoz2o= X-Received: by 2002:a6b:ee17:: with SMTP id i23mr5470573ioh.0.1575527654815; Wed, 04 Dec 2019 22:34:14 -0800 (PST) MIME-Version: 1.0 References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> In-Reply-To: From: Lorenzo Colitti Date: Thu, 5 Dec 2019 15:33:59 +0900 Message-ID: To: Roy Marples Cc: Tomek Mrugalski , Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000337d2f0598ef1e28" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 06:34:18 -0000 --000000000000337d2f0598ef1e28 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 1:46 PM Roy Marples wrote: > I'm not fully following here. > DISOVER - DHCP optional > server says - OK, retry around T2 (our new option) > > vs > > DISCOVER - No new option, I want a lease > server says - Sure! here's T1 and T2 timers > The problem is that these two packets are the same except for one option. >From the perspective of a recipient that does not understand the option, those two packets are exactly the same. --000000000000337d2f0598ef1e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 1:46 PM Roy Marple= s <roy@marples.name> wrote:
I'm not fully following here.
DISOVER - DHCP optional
server says - OK, retry around T2 (our new option)

vs

DISCOVER - No new option, I want a lease
server says - Sure! here's T1 and T2 timers

The problem is that these two packets are the same except for one = option. From the perspective of a recipient that does not understand the op= tion, those two packets are exactly the same.
--000000000000337d2f0598ef1e28-- From nobody Wed Dec 4 22:42:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C141200D5 for ; Wed, 4 Dec 2019 22:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 eKtyLysLcMhD for ; Wed, 4 Dec 2019 22:42:06 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD8B120059 for ; Wed, 4 Dec 2019 22:42:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB56g2Ux007904 for ; Thu, 5 Dec 2019 07:42:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 903FF20111C for ; Thu, 5 Dec 2019 07:42:02 +0100 (CET) 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 868F8200BF0 for ; Thu, 5 Dec 2019 07:42:02 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xB56g2aw015318 for ; Thu, 5 Dec 2019 07:42:02 +0100 To: V6 Ops List References: From: Alexandre Petrescu Message-ID: Date: Thu, 5 Dec 2019 07:42:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 06:42:08 -0000 Hi, v6opsers, Are we supposed to discuss this draft now? Alex Le 04/12/2019 à 13:09, Jen Linkova a écrit : > Hello, > > One of the biggest issue in deploying IPv6-only LANs is how to do it > incrementally, when some hosts work just fine in NAT64 environment > while some legacy devices still need IPv4. Doubling the number of > network segments (having an IPv6-only and dual-stack segments of each > type) is an operational nightmare. So it would be just awesome if all > devices can co-exist in the same network segment and hosts capable of > operating in IPv6-only environment do not consume IPv4 addresses. > So here is the draft proposing a new DHCPv4 option to help saving IPv4 > addresses and deploying IPv4-as-a-service: > > Name: draft-link-dhc-v6only > Revision: 00 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-04 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only > > > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining a IPv4 > address if the network provides IPv6 access. > > Any comments/suggestions/reviews are highly appreciated! > > Adding v6ops@ to Cc: as the problem is related to operating IPv6-only networks. > > Thank you! > From nobody Wed Dec 4 23:01:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D210A120059; Wed, 4 Dec 2019 23:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfk1gU0x5zqg; Wed, 4 Dec 2019 23:01:29 -0800 (PST) Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2BD120096; Wed, 4 Dec 2019 23:01:29 -0800 (PST) Received: by mail-qv1-xf42.google.com with SMTP id t5so911495qvs.5; Wed, 04 Dec 2019 23:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DLBRk41jf03ru8mMdUsqk1vqU4PQnmJxImb/gf3yRH8=; b=A67dv5rTdDNPYPXhC9mLxVdtcRoeXqLKVM8NycA77/CMaURhQWPGSmIzdcVJo4Man/ acKbolYNJk741mlKenh8BtvX4g1lwkFgu29k+R0Nb0m7UlJbIuXV0ShjTzf13pyiEovb 862dHsHhklzqj+6gRjfIMKmDZYIOugPS4lW/iCalwaZax7f8RjeB/NIXwxup1KT2TY3z nJK3iF4xr1ELg5nNA24871H6kKFgDpUPG7HBJj+w+fOHxjFTS7I6etwCotRMIgm0jWLz odKP4EMSPRQsN6N1apXO9zNo99UtK7O7clvpCBIgGOetRMRWcr+JcSDfG83It1mf2q1w SnbA== 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=DLBRk41jf03ru8mMdUsqk1vqU4PQnmJxImb/gf3yRH8=; b=ZiqkDLFVvlYDI1XIC8Q1Amzdk7BMyNL/Eyg4QpeTzbI3tY/1h5P+42juoyoSnYBjrH sR9T1pwqDzFpXbPlaHk7+mhsQTc5XzSYIgZISZyFCXjsN6Wx8+V9bSX4053q3ELu2eo2 QYPiJUfyIYfLLTKkISTz8HPNKLvXaqBoTcR7++lMkjtLv0yZZWaXwa00lJylGF1P7C5T mJ3V0HfdN8re6pQMN2XigVKYwyVc4GdRTWt/DG/Mbn06PdiKgXYk0W1M5tBpGUFqY8y7 GwcU7XuWy48YMZf1WXnBthP1pTIWYg8L8uQvuWiUa9qZqiV43x/v+8jwY6pbctgGW9ld HdVg== X-Gm-Message-State: APjAAAUMOop9gHvS8KKjq8Gt01GxthEAEOvQYOCO68g4hz3WDsQ7hu0A 3lEEIgN/9ILlhShj/27todG31lzed3fHAkFZ9FkaMamteBQ= X-Google-Smtp-Source: APXvYqx2mYKV3o7+TlHO1wwifBQXbnPI3AOJWVFUgcTkPiTjocMcVKqcwaoIOzGMJyqOlLfRg9DCpj/JK1PELvkcjuQ= X-Received: by 2002:a0c:eed2:: with SMTP id h18mr6231674qvs.184.1575529288013; Wed, 04 Dec 2019 23:01:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Thu, 5 Dec 2019 18:01:16 +1100 Message-ID: To: Roy Marples Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 07:01:31 -0000 On Thu, Dec 5, 2019 at 12:12 PM Roy Marples wrote: > It assmues only IPv6. > I dislike it when different protocol families discuss each other - IPv6 > should not turn off IPv4, likewise IPv4 should not turn off IPv6. > I would prefer it if Iv6 was not mentioned at all outside of a use case > for the option. There is a catch there. Right now the *only* possible scenario when a host might consider IPv4 optional is that: 1) the host supports IPv6 2) either all applications on that host work in NAT64 environment or the host is doing 464XLAT. 3) the network provides NAT64. The host knows if conditions #1 and #2 are met and signals it to the network, so DHCP server responds 'OK, #3 is met as well'. Now if we stop assuming IPv6 - even worse, if we stop assuming NAT64 being the only transition mechanism - we might end up in a following situation: [host] : dear network, IPv4 is optional for me (because the host can work in NAT64 environment) [ the network] ah great, we've been trying to reduce IPv4 footprint so we deployed IPv15 and the corresponding transition mechanisms, namely NAT15-to-4, so I'm not going to give an address. So the host is willing to make IPv4 optional *conditionally* and currently that condition is 'NAT64'. We either explicitly describe that condition in the draft or - as it's been suggested in the thread - we start encoding it in the option. So if the option value is '1' it means 'IPv6-Only with NAT64', value 2 - some other 6-to-4 transition technology we might invent tomorrow, and 3 - some shiny IPv4-to-IPv15 thingy. > > The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT seconds. > > Is the wait seconds even needed? > Just set the T2 timer and treat it as leasing the unspecified address. > Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides > nothing of value as I see it. I suspect it would complicate the configuration. Currently my lease time is 30 mins. But I do not want IPv6-only capable clients to come back so often, so I'd be probably setting V6ONLY_WAIT to a number of hours. While IPv4 clients will continue to receive short lease time. -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 23:08:38 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8B4120096 for ; Wed, 4 Dec 2019 23:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW0MaygAIAqs for ; Wed, 4 Dec 2019 23:08:36 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A16120059 for ; Wed, 4 Dec 2019 23:08:36 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id d124so2476898qke.6 for ; Wed, 04 Dec 2019 23:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JiwdbUCYXiAxUmtdIH+f1K5nQg4vhZqhhg4KwL9kkl0=; b=IdZCYYM4QQljxNb509CbS+vMV1WZnd5oe/kt2CZdyV5gEKd9PWymdW8gId+KDZdZ7Z 0dFgwWzijcGxD8bvtxrJ1mroXuMooeqWeiwM+904DcdnzJxSziOiG66oUEtjYalGFb3T Ld34J4QlsspdmC4npEpHe9G+mhtmkWPnuTW1ZqoUwV4HqcnM6CzlSzq76JMXdCq4Dff5 +OPEU/K7yyDMVqyFLke3cL5SnURIpJJepaCrrQjtjPeSJytgubE+zG2reBtwCKIjtiPz S272TP5L+ZTUDQUNvDdP1XYRX5YHv+Ya5EFBHazk6ukBAn95Gh8TFsDWZaDZ4zMwS/TR Qgdg== 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=JiwdbUCYXiAxUmtdIH+f1K5nQg4vhZqhhg4KwL9kkl0=; b=dBIwNiN3dJ7qjHGTN0HmagJzYJOGGJzEqeS029gJbCo6w+yIXrlPg5LDpFMgth/cRf ioIpZpfu7CLjsQ17Gp2DnOhDXfEO5lKTS/9VRRt6l1J95OFlqTdem0n6o2TSrwiE+lA1 xEy7kX78yR/M+E3iaYEleBbBhaXvtEKo6RUcYcTQZMa2nTYUKuAdx5eQMJcBx+UwLxEt vKPQHFxA4Svti1YJwJzgzW9wxmA3yYlmc3CKaRdgWfd/zyPgvkhMfEhde5LdOEKZ6oAa LdIirDEiNDeArdb+R1LvUaQOuOZI6lD+r6+I3oy/mEiXWoqpxG+YtWq2TGdyEPVZE0UI EtEw== X-Gm-Message-State: APjAAAUm7Ikq0JrSQn+u8suR4U2lFRZePrfGQkQgEkKC9YuUU5yUYohO EHN2Vr+701fGZCPxQKt/LOHRrSrvhhDUZdbxZMI= X-Google-Smtp-Source: APXvYqxB3gb8mFb5hjKd5WU9adLP2OG2iizm7oLs+E2lja/9gPcfwj9kg8TbIR/9n2yeboCCUEt2rkKpckRomns1hXk= X-Received: by 2002:a05:620a:6ce:: with SMTP id 14mr6691244qky.417.1575529715557; Wed, 04 Dec 2019 23:08:35 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <7b646344-d0b7-ee6e-d732-4e10898b61e3@si6networks.com> <9a80258d-f001-3be5-96fe-c416ad50bde2@si6networks.com> In-Reply-To: <9a80258d-f001-3be5-96fe-c416ad50bde2@si6networks.com> From: Jen Linkova Date: Thu, 5 Dec 2019 18:08:23 +1100 Message-ID: To: Fernando Gont Cc: Brian E Carpenter , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 07:08:37 -0000 On Thu, Dec 5, 2019 at 4:52 PM Fernando Gont wrote: > Let me rephrase my question. What are the semantics of the option? "Turn > off IPv4?" -- "Turn off IPv4 if $CONDITION is met". Currently $CONDITION is hardcoded in the draft as 'NAT64'. It is critical that both server and the client assume the same condition. > If that's the semantics, then what triggered the use of > the option, from the pov of the ipv4 host, is rather irrelevant. It is relevant. We do not want the host to send the option because it supports NAT64 environment, while the server is responding with the option because the administrator enabled IPX for that segment. > Side question: What if the network provides NAT64 service, but there are > local nodes that do not implement IPv6 (e.g., printers)? Those nodes will continue receive IPv4 addresses. If your question is 'how IPv6-only hosts on that segment would talk to those IPv4-only devices' - well, they would not. If I need to migrate a segment to IPv6-mostly mode I would not put any IPv4-only services there which IPv6-only devices need to access. Pls remember that the administrator needs to explicitly enable this functionality for the network segment. -- SY, Jen Linkova aka Furry From nobody Wed Dec 4 23:55:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3411200F4; Wed, 4 Dec 2019 23:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STVN4iIZZThS; Wed, 4 Dec 2019 23:55:03 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A751200B3; Wed, 4 Dec 2019 23:55:02 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 47T7Kw1N7kz4wJf; Thu, 5 Dec 2019 08:55:00 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 47T7Kw0bxrz1xpp; Thu, 5 Dec 2019 08:55:00 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 08:54:59 +0100 From: To: Jen Linkova CC: =?utf-8?B?QmrDuHJuIE1vcms=?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVquz/pq5GW9sfF0KRMvO8RARyP6erKaXw Date: Thu, 5 Dec 2019 07:54:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 07:55:05 -0000 SGkgSmVuLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSmVuIExpbmtvdmEgW21haWx0bzpmdXJy eTEzQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSA0IGTDqWNlbWJyZSAyMDE5IDIy OjUyDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogQmrDuHJuIE1v cms7IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlzdDsgZHJhZnQtbGluay1kaGMtDQo+IHY2b25s eUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2RoY3dnXSBJUHY2LU9ubHkgUHJlZmVycmVkIERI Q1B2NCBvcHRpb24NCj4gDQo+IE9uIFRodSwgRGVjIDUsIDIwMTkgYXQgMTI6NTYgQU0gPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+IEJsaW5kbHkgcmVsZWFzaW5nIHRo ZSBJUHY0IGFkZHJlc3Mgd2hlbiBhbiBJUHY2IGNvbm5lY3Rpdml0eSBpcyBhdmFpbGFibGUNCj4g aXMgcHJvYmxlbWF0aWMgYmVjYXVzZSB0aGUgaG9zdCBkb2VzIG5vdCBrbm93IGlmIGEgTkFUNjQg ZnVuY3Rpb24gaXMNCj4gYXZhaWxhYmxlIGZvciBhIGdpdmVuIG5ldHdvcmsgYXR0YWNobWVudC4g QSBob3N0IHRoYXQgZGlzY292ZXJzIHRoZQ0KPiBwcmVzZW5jZSBvZiBOQVQ2NCAoYmVjYXVzZSBh IHByZWY2NCB3YXMgZGlzY292ZXJlZCkgY2FuIHNhZmVseSByZWxlYXNlIGFueQ0KPiBhc3NpZ25l ZCBJUHY0IGFkZHJlc3MuIE5vIGFkZGl0aW9uYWwgc2lnbmFsIGlzIG5lZWRlZCBpbiBzdWNoIGNh c2UuDQo+IA0KPiBpdCB3b3VsZCBiZSBubyBkaWZmZXJlbmNlIGZyb20gd2hhdA0KPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLWlwdjZvbmx5LWZsYWcgd2FzDQo+ IHByb3Bvc2luZy4gQW5kIGFzIG1hbnkgb2YgdXMga25vdywgdGhhdCBkcmFmdCB3YXMgbm90IGFi bGUgdG8gcmVhY2gNCj4gY29uc2Vuc3VzLCB0aGUgbWFpbiBvYmplY3Rpb24gYmVpbmcgJ3dlIGNh biBub3QgYWxsb3cgYW4gSVB2NiBwYWNrZXQNCj4gdG8gdHVybiBvZmYgSVB2NCcuDQo+IFdoYXQg ZGhjLXY2b25seSBkcmFmdCBkb2VzIGlzICBhbGxvd2luZyB0aGUgREhDUHY0IHNlcnZlciB0byBi ZQ0KPiBjb25maWd1cmVkIGluIHN1Y2ggd2F5IHRoYXQgIGhvc3RzIGNhbiBzZWxlY3RpdmVseSB0 dXJuIG9mZiBJUHY0LiBObw0KPiBJUHY2IHRyYWZmaWMgaW52b2x2ZWQsIGV2ZXJ5dGhpbmcgb3Bl cmF0ZXMgb3ZlciBJUHY0Lg0KPiANCj4gPiBKZW4sIGRvIHlvdSBoYXZlIGEgY2FzZSB3aGVyZSB5 b3Ugd2FudCB0byBkZXBsb3kgSVB2Ni1vbmx5IGhvc3Qgd2l0aG91dA0KPiBhbm5vdW5jaW5nIHBy ZWY2NCB0byB0aGF0IGhvc3Q/DQo+IA0KPiBJICphbSogZGVwbG95aW5nIHRoZW0gcmlnaHQgbm93 LCBiZWNhdXNlIHByZWY2NCBkcmFmdCBpcyB3aXRoIElFU0cNCj4gcmlnaHQgbm93IGFuZCBtYW55 IG9mIG15IHJvdXRlcnMgYXJlIG5vdCBhYmxlIHRvIHNlbmQgb3V0IFBSRUY2NCBSQQ0KPiBvcHRp b24geWV0Lg0KDQpbTWVkXSBJIHRoaW5rIHRoaXMgZGVzaWduIGlzIHN1Ym9wdGltYWwuIA0KDQpJ bnN0ZWFkIG9mIHJlcXVpcmluZyBhIFBSRUZJWDY0IFJBIG9wdGlvbiAoY2hhbmdlcyB0byBob3N0 cy9yb3V0ZXJzKSArIERIQ1Agb3B0aW9uIChjaGFuZ2VzIHRvIGhvc3RzL2RoY3Agc2VydmVyKSB0 byBzb2x2ZSB5b3VyIHByb2JsZW0sIHlvdSBjYW4gYWNoaWV2ZSB0aGUgc2FtZSBnb2FsIHdpdGgg b25lIHNpbmdsZSBESENQIG9wdGlvbiAoUFJFRjY0KSBhbmQgd2l0aG91dCB0b3VjaGluZyB0byB0 aGUgcm91dGVycy4gDQoNCj4gDQo+IEkgYWdyZWUgdGhhdCBpbiB0aGVvcnkgcHJlZjY0IHByZXNl bmNlIGlzIGEgdmVyeSBnb29kIGltcGxpY2l0IHNpZ25hbA0KPiBmb3IgJ3lvdSBkb24ndCByZWFs bHkgbmVlZCBJUHY0Jy4gSG93ZXZlciB3aGVuIGEgaG9zdCBjb25uZWN0cyB0byBhDQo+IG5ldHdv cmsgaXQgZG9lcyBub3Qga25vdyBpZiBwcmVmNjQgaXMgYXZhaWxhYmxlIHdoZW4gaXQgc3RhcnRz IERIQ1B2NA0KPiBwcm9jZXNzLiBTbyB0byB1c2UgUkFzIGFzIGEgc2lnbmFsIHlvdSBuZWVkIHRv IGVpdGhlciBkZWxheSBESENQdjQgKD09DQo+IHBlbmFsaXplIHY0LW9ubHkgYW5kIGR1YWwtc3Rh Y2sgbmV0d29ya3MpIG9yIGRvIGFsbCB0aG9zZSB1bmRlc2lyYWJsZQ0KPiBSRUxFQVNFIHRyaWNr cyBsYXRlci4NCg0KW01lZF0gVGhlIG1hY2hpbmVyeSB3aWxsIGJlIGFsbW9zdCB0aGUgc2FtZSBh cyB5b3UgYXJlIGRvaW5nIHdpdGggeW91ciBuZXcgb3B0aW9uLiBZb3UgZG9uJ3QgbmVlZCB0byBk ZWxheSBESENQdjQuIFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhlIHNpZ25hbCBvbiB3aGljaCB0 byByZWx5IHRvIG1ha2UgdGhlIGRlY2lzaW9uLg0KDQpORVc6DQogICBUaGUgY2xpZW50IE1VU1Qg Tk9UIGNvbmZpZ3VyZSB0aGUgSVB2NCBhZGRyZXNzIHByb3ZpZGVkIA0KICAgaW4gdGhlIERIQ1BP RkZFUiBpZiB0aGUgY2xpZW50IGRpc2NvdmVycyBhIHZhbGlkIFBSRUY2NC4NCiAgDQoNCj4gSSBi ZWxpZXZlIHRoaXMgaXMgZGlzY3Vzc2VkIGluIHRoZSBJbnRyb2R1Y3Rpb24gYW5kIHRoZSBTZWN0 aW9uIDIgb2YNCj4gdGhlIGRyYWZ0IGJ1dCBJJ2xsIGxvb2sgaW50byBob3cgdG8gY2xhcmlmeSB0 aGUgdGV4dC4NCj4gDQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERl IDogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEJq w7hybiBNb3JrDQo+ID4gPiBFbnZvecOpIDogbWVyY3JlZGkgNCBkw6ljZW1icmUgMjAxOSAxNDoz MQ0KPiA+ID4gw4AgOiBKZW4gTGlua292YQ0KPiA+ID4gQ2MgOiBkaGN3Z0BpZXRmLm9yZzsgVjYg T3BzIExpc3Q7IGRyYWZ0LWxpbmstZGhjLXY2b25seUBpZXRmLm9yZw0KPiA+ID4gT2JqZXQgOiBS ZTogW2RoY3dnXSBJUHY2LU9ubHkgUHJlZmVycmVkIERIQ1B2NCBvcHRpb24NCj4gPiA+DQo+ID4g PiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyaXRlczoNCj4gPiA+DQo+ID4gPiA+ IEhlbGxvLA0KPiA+ID4gPg0KPiA+ID4gPiBPbmUgb2YgdGhlIGJpZ2dlc3QgaXNzdWUgaW4gZGVw bG95aW5nIElQdjYtb25seSBMQU5zIGlzIGhvdyB0byBkbyBpdA0KPiA+ID4gPiBpbmNyZW1lbnRh bGx5LCB3aGVuIHNvbWUgaG9zdHMgd29yayBqdXN0IGZpbmUgaW4gTkFUNjQgZW52aXJvbm1lbnQN Cj4gPiA+ID4gd2hpbGUgc29tZSBsZWdhY3kgZGV2aWNlcyBzdGlsbCBuZWVkIElQdjQuIERvdWJs aW5nIHRoZSBudW1iZXIgb2YNCj4gPiA+ID4gbmV0d29yayBzZWdtZW50cyAoaGF2aW5nIGFuIElQ djYtb25seSBhbmQgZHVhbC1zdGFjayBzZWdtZW50cyBvZiBlYWNoDQo+ID4gPiA+IHR5cGUpIGlz IGFuIG9wZXJhdGlvbmFsIG5pZ2h0bWFyZS4gU28gaXQgd291bGQgYmUganVzdCBhd2Vzb21lIGlm IGFsbA0KPiA+ID4gPiBkZXZpY2VzIGNhbiBjby1leGlzdCBpbiB0aGUgc2FtZSBuZXR3b3JrIHNl Z21lbnQgYW5kIGhvc3RzIGNhcGFibGUgb2YNCj4gPiA+ID4gb3BlcmF0aW5nIGluIElQdjYtb25s eSBlbnZpcm9ubWVudCBkbyBub3QgY29uc3VtZSBJUHY0IGFkZHJlc3Nlcy4NCj4gPiA+ID4gU28g aGVyZSBpcyB0aGUgZHJhZnQgcHJvcG9zaW5nIGEgbmV3IERIQ1B2NCBvcHRpb24gdG8gaGVscCBz YXZpbmcNCj4gSVB2NA0KPiA+ID4gPiBhZGRyZXNzZXMgYW5kIGRlcGxveWluZyBJUHY0LWFzLWEt c2VydmljZToNCj4gPiA+ID4NCj4gPiA+ID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhj LXY2b25seQ0KPiA+ID4gPiBSZXZpc2lvbjogICAgICAgMDANCj4gPiA+ID4gVGl0bGU6ICAgICAg ICAgIElQdjYtT25seS1QcmVmZXJyZWQgT3B0aW9uIGZvciBESENQDQo+ID4gPiA+IERvY3VtZW50 IGRhdGU6ICAyMDE5LTEyLTA0DQo+ID4gPiA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gPiA+ID4gUGFnZXM6ICAgICAgICAgIDkNCj4gPiA+ID4gVVJMOg0KPiA+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGluay1kaGMtdjZv bmx5LTAwLnR4dA0KPiA+ID4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbGluay1kaGMtDQo+IHY2b25seS8NCj4gPiA+ID4gSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9ubHkt MDANCj4gPiA+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtbGluay1kaGMtDQo+ID4gPiB2Nm9ubHkNCj4gPiA+ID4NCj4gPiA+DQo+ ID4gPiAgICJXaGlsZSBJUHY2LW9ubHkgY2FwYWJsZSBkZXZpY2VzIG1pZ2h0IHVzZSBhDQo+ID4g PiAgICBoZXVyaXN0aWMgYXBwcm9hY2ggdG8gbGVhcm5pbmcgaWYgdGhlIG5ldHdvcmsgcHJvdmRl cyBJUHY2LW9ubHkNCj4gPiA+ICAgIGZ1bmN0aW9uYWxpdHkgYW5kIHN0b3AgdXNpbmcgSVB2NCBp ZiBpdCBkb2VzLCBpdCBtaWdodCBiZQ0KPiBwcmFjdGljYWxseQ0KPiA+ID4gICAgdW5kZXNpcmFi bGUuICBPbmUgaW1wb3J0YW50IHJlYXNvbiBpcyB0aGF0IHdoZW4gYSBob3N0IGNvbm5lY3RzIHRv IGENCj4gPiA+ICAgIG5ldHdvcmssIGl0IGRvZXMgbm90IGtub3cgaWYgdGhlIG5ldHdvcmsgaXMg SVB2NC1vbmx5LCBkdWFsLXN0YWNrIG9yDQo+ID4gPiAgICBJUHY2LW9ubHkuICBUbyBlbnN1cmUg dGhhdCB0aGUgY29ubmVjdGl2aXR5IG92ZXIgd2hhdGV2ZXIgcHJvdG9jb2wNCj4gaXMNCj4gPiA+ ICAgIHByZXNlbnQgYmVjb21lcyBhdmFpbGFibGUgYXMgc29vbiBhcyBwb3NzaWJsZSB0aGUgaG9z dCB1c3VhbGx5DQo+IHN0YXJ0cw0KPiA+ID4gICAgY29uZmlndXJpbmcgYm90aCBJUHY0IGFuZCBJ UHY2IGltbWlkaWF0ZWx5LiAgSWYgaG9zdHMgd2VyZSB0byBkZWxheQ0KPiA+ID4gICAgcmVxdWVz dGluZyBJUHY0IHVudGlsIElQdjYgcmVhY2hhYmlsaXR5IGlzIGNvbmZpcm1lZCwgdGhhdCB3b3Vs ZA0KPiA+ID4gICAgd291bGQgcGVuYWxpemUgSVB2NC1vbmx5IGFuZCBkdWFsLXN0YWNrIG5ldHdv cmtzLCB3aGljaCBkb2VzIG5vdA0KPiBzZWVtDQo+ID4gPiAgICBwcmFjdGljYWwuICINCj4gPiA+ DQo+ID4gPg0KPiA+ID4gV2h5IGNhbid0IHRoZSBjbGllbnQganVzdCByZWxlYXNlIHRoZSBJUHY0 IGFkZHJlc3Mgd2hlbiBpdCBmaW5kcyBpdCBoYXMNCj4gPiA+IElQdjYgY29ubmVjdGl2aXR5PyAg VGhpcyB3b3VsZCBhbHNvIGF2b2lkIHRoZSBwcm9ibGVtcyB5b3UgaW50cm9kdWNlDQo+ID4gPiB3 aGVuIHRoZSBuZXR3b3JrIGZhbHNlbHkgY2xhaW1zIElQdjYgc3VwcG9ydC4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4NCj4gPiA+IEJqw7hybg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4g PiA+IGRoY3dnQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnDQo+IA0KPiANCj4gDQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBha2EgRnVy cnkNCg== From nobody Thu Dec 5 00:14:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC0A1200F5 for ; Thu, 5 Dec 2019 00:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 caTaZEslciAW for ; Thu, 5 Dec 2019 00:13:57 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467291200B3 for ; Thu, 5 Dec 2019 00:13:57 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id k24so2683997ioc.4 for ; Thu, 05 Dec 2019 00:13:57 -0800 (PST) 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=VGFi6ts3YcHe7dPik7Pg4VsAPCQbxt5goujYhFy51gg=; b=Av1uOk0xGaTsB+gXxl3c/OZaXV5qW1J2XIYB3UVaeksh/RzBFXDyifhSfxFRP0cCjv gUaCHlphmFKBznRbpWY9i+naigtN2l/ZPAiX44Bd4Rotvm6mzmIox44LepCkYkBF1Z5R rBOutQtLqAUFlgJjlMcPHomIfC+fEQVUujpHYXH4gEhYjAgJsFzg1VjLoXY2gmyRwrwF UYFUDyQkCAMcNHLIfUpxHdpwleoMVkCtsrCZ2txwUnzWzna8dntcj70s5xyEIvHNc/b3 ceAQD9YxxEZ9xRTnEKUXWy/OUIVwbD4hp4dB9LiMe0RUxyQxqSBKv0qZeLzXKaKIlowp QGqQ== 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=VGFi6ts3YcHe7dPik7Pg4VsAPCQbxt5goujYhFy51gg=; b=qd7IXvLAzzfecNK0iqeeAbMwf+yRd37176gd60XOdsP+bxmAysta6pVbu6h+j04YuK ukD/bkIm4WHW28x3i8JpNuy9wOVGE9EIH4G2TmmPOsS697PbGPRTFzZJ95bREWYLmkaa rOmcTN7ReqMd+daEPJyxyQ+C9r6g7Zyzzv1WlaX5j1j9EZ3t1oL4JLEwraqKIPbph5My a974C+cdSH/ezgxKGcwWLVbd3tXm0XTLos53Ch54H+ZOaYg5OWBze/YvoHQgXWBQoxUx VC+Ssm2fxT/cgZlGhitm4lkC9SS8NuOQ7+V5D4Je+CC2JZNgVs/JRR9gXX2OZIDNdGKj 0vgw== X-Gm-Message-State: APjAAAXbJtqz6jZntXnO7NVqYrQgHWN62+m17O3PzyY5lKry8NtjCBqW bDe7ky0sUyd/m8CLRwoASkoCv30TCFI1l3R2jOz14g== X-Google-Smtp-Source: APXvYqyKaLJL61Vy1A64r3AyOey7f8nX8JX/6c/guTXYyUwlBaExpcM0kCqlwlNGxJwA9V13p527bfqraEYoe5uPA/E= X-Received: by 2002:a5d:9249:: with SMTP id e9mr5528337iol.242.1575533636232; Thu, 05 Dec 2019 00:13:56 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 17:13:44 +0900 Message-ID: To: "" Cc: Jen Linkova , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b896e70598f08259" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 08:13:59 -0000 --000000000000b896e70598f08259 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 4:55 PM wrote: > > I agree that in theory pref64 presence is a very good implicit signal > > for 'you don't really need IPv4'. However when a host connects to a > > network it does not know if pref64 is available when it starts DHCPv4 > > process. So to use RAs as a signal you need to either delay DHCPv4 (== > > penalize v4-only and dual-stack networks) or do all those undesirable > > RELEASE tricks later. > > [Med] The machinery will be almost the same as you are doing with your new > option. You don't need to delay DHCPv4. The only difference is the signal > on which to rely to make the decision. > I don't think that works. What is needed is a signal to the host that IPv4 should not be used if the host is capable of IPv6-only operation. That signal *must* be available before DHCPv4 assigns an address to the interface, because once an address is assigned, the host will not wait for anything else and will allow apps using it immediately. This is by design; it ensures that IPv4-only networks are as fast as they possibly can be. Therefore, this signal cannot be in any IPv6 packet, including an RA, a RFC 7050 DNS reply, a PCP NAT64 option, or a DHCPv6 option. --000000000000b896e70598f08259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 4:55 PM <mohamed.boucadair@orange.com&= gt; wrote:
> I agree that in theory pref64 presence is a very= good implicit signal
> for 'you don't really need IPv4'. However when a host conn= ects to a
> network it does not know if pref64 is available when it starts DHCPv4<= br> > process. So to use RAs as a signal you need to either delay DHCPv4 (= =3D=3D
> penalize v4-only and dual-stack networks) or do all those undesirable<= br> > RELEASE tricks later.

[Med] The machinery will be almost the same as you are doing with your new = option. You don't need to delay DHCPv4. The only difference is the sign= al on which to rely to make the decision.

I don't think that works. What is needed is a signal to the host tha= t IPv4 should not be used if the host is capable of IPv6-only operation. Th= at signal *must* be available before DHCPv4 assigns an address to the inter= face, because once an address is assigned, the host will not wait for anyth= ing else and will allow apps using it immediately. This is by design; it en= sures that IPv4-only networks are as fast as they possibly can be. Therefor= e, this signal cannot be in any IPv6 packet, including an RA, a=C2=A0RFC 70= 50 DNS reply, a PCP NAT64 option, or a DHCPv6 option.
--000000000000b896e70598f08259-- From nobody Thu Dec 5 00:42:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBD01200F5 for ; Thu, 5 Dec 2019 00:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 b1RO9uq7vdUn for ; Thu, 5 Dec 2019 00:42:44 -0800 (PST) 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 6BDA31200F1 for ; Thu, 5 Dec 2019 00:42:44 -0800 (PST) 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 m1icmif-0000JrC; Thu, 5 Dec 2019 09:42:41 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-reply-to: Your message of "Thu, 5 Dec 2019 08:53:11 +1300 ." <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> Date: Thu, 05 Dec 2019 09:42:41 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 08:42:46 -0000 In your letter dated Thu, 5 Dec 2019 08:53:11 +1300 you wrote: >As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoi >d IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell h >osts to prefer IPv6 will also be accused of being an operational nightmare. I think this draft has different issues. The good thing about this draft is that it doesn't affect legacy networks or legacy hosts. It also doesn't affect any host that doesn't implement this draft. The good thing about this mechanism is that it is the DHCP server that decides what to do. Given that the DHCP servers hand out IPv4 addresses, we already need to trust the DHCP server. So this draft clearly put functionality where it belongs. I'm not sure that it makes sense for an operator to implement this draft. Though I have to admit, this draft could finally end the discusion on whether the default SSID on a meeting network should be NAT64 or dual stack. With this option it would be upto the host to pick the right way of doing IPv4. From nobody Thu Dec 5 00:49:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639121200F1 for ; Thu, 5 Dec 2019 00:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 cUo1clbI06Rv for ; Thu, 5 Dec 2019 00:49:28 -0800 (PST) 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 8DC271200F6 for ; Thu, 5 Dec 2019 00:49:28 -0800 (PST) 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 m1icmpA-0000KmC; Thu, 5 Dec 2019 09:49:24 +0100 Message-Id: To: v6ops@ietf.org Cc: Lorenzo Colitti From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-reply-to: Your message of "Thu, 5 Dec 2019 11:19:52 +0900 ." Date: Thu, 05 Dec 2019 09:49:24 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 08:49:29 -0000 >Speaking as an OS implementer: how do I know whether an application is an >IPv4 application? > > - When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do > that. > - When it creates an IPv4 socket? But what if it's creating an IPv4 > socket for the purpose of connecting to another network on the system > (e.g., cellular data) that does have IPv4? > - When it does a connect() on an IPv4 socket? But what if that's just a > happy eyeballs stack that is using IPv4 because it might be available? > - What if the app knows it needs IPv4 and will refuse to do any > networking if it doesn't find an IPv4 address on the system? I agree with Lorenzo here. Changing a host to defer trying to get an IPv4 address while at the same time not showing any delay to the user when the device connects to a new network would be an enormous amount of effort with essentally no benefit to the vendor of the host device. From nobody Thu Dec 5 00:59:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020A11200F6; Thu, 5 Dec 2019 00:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUbHWitn599U; Thu, 5 Dec 2019 00:58:56 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3D81200F1; Thu, 5 Dec 2019 00:58:55 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 47T8lf3355zywd; Thu, 5 Dec 2019 09:58:54 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 47T8ld6sYWzDq8l; Thu, 5 Dec 2019 09:58:53 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:58:54 +0100 From: To: Lorenzo Colitti CC: Jen Linkova , =?utf-8?B?QmrDuHJuIE1vcms=?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVq0Py0EzcIgM90k+qjQhPGFF0raerPXRQ Date: Thu, 5 Dec 2019 08:58:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E429BOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 08:58:59 -0000 --_000_787AE7BB302AE849A7480A190F8B9330313E429BOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KSU1PLCBhIGhvc3Qgd2lsbCBuZWVkIHRvIOKAnHBhdXNl4oCdIHRoZSB2NCBj b25maWd1cmF0aW9uIGZvciB4eHggbXMgdG8gbWFrZSBzdXJlIHRoZSBjb25maWd1cmF0aW9uICh2 NC92NikgaXMgY29uc2lzdGVudC4NCg0KQ29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgYW4gYXBwbGlj YXRpb24gdGhhdCBuZWVkcyBDTEFUIHRvIHdvcmsuIEV2ZW4gaWYgdGhlIERIQ1B2NCByZXR1cm5z IGEgc2lnbmFsIHRoYXQgaXQgaXMgc2FmZSB0byByZWxlYXNlIHRoZSBJUHY0IGFkZHJlc3MsIHRo YXQgYXBwbGljYXRpb24gd2lsbCBuZWVkIHRvIHdhaXQgZm9yIHRoZSBQUkVGNjQgdG8gd29yay4g VGhlIGRlbGF5IGZvciB0aGF0IGFwcGxpY2F0aW9uIHdpbGwgYmUgdGhlIHNhbWUuDQoNCkNoZWVy cywNCk1lZA0KDQpEZSA6IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bV0NCkVudm95w6kgOiBqZXVkaSA1IGTDqWNlbWJyZSAyMDE5IDA5OjE0DQrDgCA6IEJPVUNBREFJ UiBNb2hhbWVkIFRHSS9PTE4NCkNjIDogSmVuIExpbmtvdmE7IEJqw7hybiBNb3JrOyBkaGN3Z0Bp ZXRmLm9yZzsgVjYgT3BzIExpc3Q7IGRyYWZ0LWxpbmstZGhjLXY2b25seUBpZXRmLm9yZw0KT2Jq ZXQgOiBSZTogW2RoY3dnXSBJUHY2LU9ubHkgUHJlZmVycmVkIERIQ1B2NCBvcHRpb24NCg0KT24g VGh1LCBEZWMgNSwgMjAxOSBhdCA0OjU1IFBNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+IEkgYWdyZWUg dGhhdCBpbiB0aGVvcnkgcHJlZjY0IHByZXNlbmNlIGlzIGEgdmVyeSBnb29kIGltcGxpY2l0IHNp Z25hbA0KPiBmb3IgJ3lvdSBkb24ndCByZWFsbHkgbmVlZCBJUHY0Jy4gSG93ZXZlciB3aGVuIGEg aG9zdCBjb25uZWN0cyB0byBhDQo+IG5ldHdvcmsgaXQgZG9lcyBub3Qga25vdyBpZiBwcmVmNjQg aXMgYXZhaWxhYmxlIHdoZW4gaXQgc3RhcnRzIERIQ1B2NA0KPiBwcm9jZXNzLiBTbyB0byB1c2Ug UkFzIGFzIGEgc2lnbmFsIHlvdSBuZWVkIHRvIGVpdGhlciBkZWxheSBESENQdjQgKD09DQo+IHBl bmFsaXplIHY0LW9ubHkgYW5kIGR1YWwtc3RhY2sgbmV0d29ya3MpIG9yIGRvIGFsbCB0aG9zZSB1 bmRlc2lyYWJsZQ0KPiBSRUxFQVNFIHRyaWNrcyBsYXRlci4NCg0KW01lZF0gVGhlIG1hY2hpbmVy eSB3aWxsIGJlIGFsbW9zdCB0aGUgc2FtZSBhcyB5b3UgYXJlIGRvaW5nIHdpdGggeW91ciBuZXcg b3B0aW9uLiBZb3UgZG9uJ3QgbmVlZCB0byBkZWxheSBESENQdjQuIFRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgdGhlIHNpZ25hbCBvbiB3aGljaCB0byByZWx5IHRvIG1ha2UgdGhlIGRlY2lzaW9uLg0K DQpJIGRvbid0IHRoaW5rIHRoYXQgd29ya3MuIFdoYXQgaXMgbmVlZGVkIGlzIGEgc2lnbmFsIHRv IHRoZSBob3N0IHRoYXQgSVB2NCBzaG91bGQgbm90IGJlIHVzZWQgaWYgdGhlIGhvc3QgaXMgY2Fw YWJsZSBvZiBJUHY2LW9ubHkgb3BlcmF0aW9uLiBUaGF0IHNpZ25hbCAqbXVzdCogYmUgYXZhaWxh YmxlIGJlZm9yZSBESENQdjQgYXNzaWducyBhbiBhZGRyZXNzIHRvIHRoZSBpbnRlcmZhY2UsIGJl Y2F1c2Ugb25jZSBhbiBhZGRyZXNzIGlzIGFzc2lnbmVkLCB0aGUgaG9zdCB3aWxsIG5vdCB3YWl0 IGZvciBhbnl0aGluZyBlbHNlIGFuZCB3aWxsIGFsbG93IGFwcHMgdXNpbmcgaXQgaW1tZWRpYXRl bHkuIFRoaXMgaXMgYnkgZGVzaWduOyBpdCBlbnN1cmVzIHRoYXQgSVB2NC1vbmx5IG5ldHdvcmtz IGFyZSBhcyBmYXN0IGFzIHRoZXkgcG9zc2libHkgY2FuIGJlLiBUaGVyZWZvcmUsIHRoaXMgc2ln bmFsIGNhbm5vdCBiZSBpbiBhbnkgSVB2NiBwYWNrZXQsIGluY2x1ZGluZyBhbiBSQSwgYSBSRkMg NzA1MCBETlMgcmVwbHksIGEgUENQIE5BVDY0IG9wdGlvbiwgb3IgYSBESENQdjYgb3B0aW9uLg0K --_000_787AE7BB302AE849A7480A190F8B9330313E429BOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5Mb3JlbnpvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPklNTywgYSBob3N0IHdpbGwgbmVlZCB0byDigJxwYXVzZeKAnSB0aGUgdjQgY29u ZmlndXJhdGlvbiBmb3IgeHh4IG1zIHRvIG1ha2Ugc3VyZSB0aGUgY29uZmlndXJhdGlvbiAodjQv djYpIGlzIGNvbnNpc3RlbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIGFuIGFwcGxpY2F0aW9u IHRoYXQgbmVlZHMgQ0xBVCB0byB3b3JrLiBFdmVuIGlmIHRoZSBESENQdjQgcmV0dXJucyBhIHNp Z25hbCB0aGF0IGl0IGlzIHNhZmUgdG8gcmVsZWFzZSB0aGUgSVB2NCBhZGRyZXNzLCB0aGF0IGFw cGxpY2F0aW9uDQogd2lsbCBuZWVkIHRvIHdhaXQgZm9yIHRoZSBQUkVGNjQgdG8gd29yay4gPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkZWxheSBmb3IgdGhhdCBhcHBsaWNhdGlv biB3aWxsIGJlIHRoZSBzYW1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENv bGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7 OjwvYj4gamV1ZGkgNSBkw6ljZW1icmUgMjAxOSAwOToxNDxicj4NCjxiPsOAJm5ic3A7OjwvYj4g Qk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gSmVuIExpbmtv dmE7IEJqw7hybiBNb3JrOyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3Q7IGRyYWZ0LWxpbmst ZGhjLXY2b25seUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtkaGN3Z10g SVB2Ni1Pbmx5IFByZWZlcnJlZCBESENQdjQgb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIERlYyA1LCAyMDE5 IGF0IDQ6NTUgUE0gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBJIGFncmVlIHRoYXQgaW4gdGhlb3J5IHByZWY2NCBwcmVzZW5jZSBpcyBhIHZlcnkgZ29v ZCBpbXBsaWNpdCBzaWduYWw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGZvciAneW91IGRvbid0IHJlYWxseSBuZWVk IElQdjQnLiBIb3dldmVyIHdoZW4gYSBob3N0IGNvbm5lY3RzIHRvIGE8YnI+DQomZ3Q7IG5ldHdv cmsgaXQgZG9lcyBub3Qga25vdyBpZiBwcmVmNjQgaXMgYXZhaWxhYmxlIHdoZW4gaXQgc3RhcnRz IERIQ1B2NDxicj4NCiZndDsgcHJvY2Vzcy4gU28gdG8gdXNlIFJBcyBhcyBhIHNpZ25hbCB5b3Ug bmVlZCB0byBlaXRoZXIgZGVsYXkgREhDUHY0ICg9PTxicj4NCiZndDsgcGVuYWxpemUgdjQtb25s eSBhbmQgZHVhbC1zdGFjayBuZXR3b3Jrcykgb3IgZG8gYWxsIHRob3NlIHVuZGVzaXJhYmxlPGJy Pg0KJmd0OyBSRUxFQVNFIHRyaWNrcyBsYXRlci48YnI+DQo8YnI+DQpbTWVkXSBUaGUgbWFjaGlu ZXJ5IHdpbGwgYmUgYWxtb3N0IHRoZSBzYW1lIGFzIHlvdSBhcmUgZG9pbmcgd2l0aCB5b3VyIG5l dyBvcHRpb24uIFlvdSBkb24ndCBuZWVkIHRvIGRlbGF5IERIQ1B2NC4gVGhlIG9ubHkgZGlmZmVy ZW5jZSBpcyB0aGUgc2lnbmFsIG9uIHdoaWNoIHRvIHJlbHkgdG8gbWFrZSB0aGUgZGVjaXNpb24u PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGRvbid0IHRoaW5rIHRoYXQgd29ya3MuIFdoYXQgaXMgbmVlZGVkIGlzIGEgc2lnbmFs IHRvIHRoZSBob3N0IHRoYXQgSVB2NCBzaG91bGQgbm90IGJlIHVzZWQgaWYgdGhlIGhvc3QgaXMg Y2FwYWJsZSBvZiBJUHY2LW9ubHkgb3BlcmF0aW9uLiBUaGF0IHNpZ25hbCAqbXVzdCogYmUgYXZh aWxhYmxlIGJlZm9yZSBESENQdjQgYXNzaWducyBhbiBhZGRyZXNzIHRvIHRoZSBpbnRlcmZhY2Us IGJlY2F1c2Ugb25jZQ0KIGFuIGFkZHJlc3MgaXMgYXNzaWduZWQsIHRoZSBob3N0IHdpbGwgbm90 IHdhaXQgZm9yIGFueXRoaW5nIGVsc2UgYW5kIHdpbGwgYWxsb3cgYXBwcyB1c2luZyBpdCBpbW1l ZGlhdGVseS4gVGhpcyBpcyBieSBkZXNpZ247IGl0IGVuc3VyZXMgdGhhdCBJUHY0LW9ubHkgbmV0 d29ya3MgYXJlIGFzIGZhc3QgYXMgdGhleSBwb3NzaWJseSBjYW4gYmUuIFRoZXJlZm9yZSwgdGhp cyBzaWduYWwgY2Fubm90IGJlIGluIGFueSBJUHY2IHBhY2tldCwgaW5jbHVkaW5nDQogYW4gUkEs IGEmbmJzcDtSRkMgNzA1MCBETlMgcmVwbHksIGEgUENQIE5BVDY0IG9wdGlvbiwgb3IgYSBESENQ djYgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330313E429BOPEXCAUBMA2corp_-- From nobody Thu Dec 5 01:00:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F107120100; Thu, 5 Dec 2019 01:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqjROGL2iBDN; Thu, 5 Dec 2019 01:00:49 -0800 (PST) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC2C1200F1; Thu, 5 Dec 2019 01:00:48 -0800 (PST) Received: from miraculix.mork.no ([IPv6:2a02:2121:2c6:3d3e:1118:ca6b:aba6:4c26]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id xB590jAF012435 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 Dec 2019 10:00:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1575536445; bh=cFeXGAbMlFqsID994buEpnnZydGzqIh4lEqII70O4O8=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=ZhfMf3hd8nsgw9OKTp3z20vj3ofeOPmJSBiY6h6gwR4/jpMGow+dG+anRX31D7JBL fhDYcjGxG4e9uuO/2eqW/6kfTDcZIQgeVyVaC15nEhMwOlJelFB2Fh3YYXIXPr8+Ls QKHkNXpof0qmDw1gTh7zje13A9ZjeOj5q94nuDZo= Received: from bjorn by miraculix.mork.no with local (Exim 4.92) (envelope-from ) id 1icn03-0005Gt-Al; Thu, 05 Dec 2019 10:00:39 +0100 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Jen Linkova Cc: Roy Marples , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Organization: m References: Date: Thu, 05 Dec 2019 10:00:39 +0100 In-Reply-To: (Jen Linkova's message of "Thu, 5 Dec 2019 18:01:16 +1100") Message-ID: <87o8wnf8p4.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.101.4 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 09:00:51 -0000 Jen Linkova writes: > Right now the *only* possible scenario when a host might consider IPv4 > optional is that: > 1) the host supports IPv6 > 2) either all applications on that host work in NAT64 environment or > the host is doing 464XLAT. > 3) the network provides NAT64. > The host knows if conditions #1 and #2 are met and signals it to the > network, so DHCP server responds 'OK, #3 is met as well'. There is a fair amount of IoT devices requiring access to one specific CDN hosted dual-stack service, and only that. These devices will always work in an IPv6 only environment, even without NAT64, and they know it. Not that these hosts ever will implement any new DHCP feature, but still.. Hosts considering NAT64 optional for IPv6-only operation will probably become more and more common as "all" (most) services get dual-stack. I believe you are limiting the scope unnecessarily by requiring NAT64 here. Bj=C3=B8rn From nobody Thu Dec 5 01:12:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1C120108 for ; Thu, 5 Dec 2019 01:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 wojG1ZDkdsB6 for ; Thu, 5 Dec 2019 01:12:12 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD7E120105 for ; Thu, 5 Dec 2019 01:12:12 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id f6so2315461ilh.9 for ; Thu, 05 Dec 2019 01:12:12 -0800 (PST) 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=V0MCgMYpj9JcQYwLPWEQh1ssyxvIsqD1oLYNZNjYEIY=; b=nXgAUiOZ8h2W+yBMCWAcqRYK6JFIkrM7SJuWmeJGujhRf3UnnUmG+DHqSqjWR5oVZm KkMdeKVFW9zNS5kv7g95HTypm9AITQ+/nkUZQd0TDGm4fn67SScz3qBPPnfDJLDfenlJ CB7fvAEyvHt+ZfLQPAO2gZw6rBcO8CDOdeFGjPjexT5ClN9H4CtbhvOhfC0IjtQjOUcs c5Y7F6Mzu0wsh0wIdHU0rZZ/UZS1byr6u/lM+yNdk+pnAsxvp9xh4IXtxz7LcaoPa7KD QjzMcMn8oK3sl8RhQ5hIrI4fqPzhmJOykZ5TDulUJBiBjbDaA1YKvWT0hAp+fQV1c5fG AizA== 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=V0MCgMYpj9JcQYwLPWEQh1ssyxvIsqD1oLYNZNjYEIY=; b=WQj7vNpPkDXDw/QwgF9VNmvMh1xR7QAu2n2gYBDY8BWzdnODs6esy1W6WxOOmho3OC IPdjdJn3Q8RUzXCsqMlVyZT444XFSTxLfUWvClMMp+gnPb75+zi5LO8jy6COwfYXO//i 1MWLit/SQMnE2SbW3uKOFaHNzr6OCDBIOe3oLB47W2AKESd/UaF/wRqwiQvuYz7QSiey ztG32aJNg8TY3m+axxNKoFHBywLb7uJBnALrCNp1FyfnYlVzh6gya7JD66EXPXtFdu/Q cg6jpvjzDC4tw+CYfTZRSfHA0MDx2jQl250ynp7Z3MWejqoyuaPEqViTOwwIStTi85IF K3tA== X-Gm-Message-State: APjAAAWrCjjJKf4/IZNktKFR6t7rziwZR2TiTyFar2d0v5Gx9iLONDVP baE5O2zgUBesbN+T8AskNXq6RZqhQ4B0zYgmbxyisg== X-Google-Smtp-Source: APXvYqy8y1eh6QD9wOr2lEy9zlyDe0jWhJlp00OtScjBuG9pDZJyQ5hO9T11VCuSOeQ5Kg3tksd8O6kPoUJMF24ejpw= X-Received: by 2002:a92:8912:: with SMTP id n18mr7971573ild.241.1575537131133; Thu, 05 Dec 2019 01:12:11 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 18:11:59 +0900 Message-ID: To: "" Cc: Jen Linkova , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Content-Type: multipart/alternative; boundary="000000000000089f160598f1539f" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 09:12:14 -0000 --000000000000089f160598f1539f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 5, 2019 at 5:58 PM wrote: > IMO, a host will need to =E2=80=9Cpause=E2=80=9D the v4 configuration for= xxx ms to make > sure the configuration (v4/v6) is consistent. > Hosts do not do this today, and I don't think they will start doing so. The reason is that they cannot tell whether another protocol will start working. If they wait xxx ms to make sure the other protocol comes up, they are slowing down all connections to single-stack networks by xxx ms, making their users unhappy. Note that IPv6 has built-in delays in the protocol itself (DAD for the link-local address; various randomized delays) that make it very difficult to get anything done before at least 1-2 seconds have passed. Hosts that know that 70% of networks are IPv4-only will not want to wait 1-2 seconds to connect to those networks. > --000000000000089f160598f1539f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 5:58 PM <mohamed.boucadair@orange.com&= gt; wrote:

IMO, a host will need to =E2=80=9Cpause= =E2=80=9D the v4 configuration for xxx ms to make sure the configuration (v= 4/v6) is consistent.


Hosts do not do this today, and I don't think they will start doing so= . The reason is that they cannot tell whether another protocol will start w= orking. If they wait xxx ms to make sure the other protocol comes up, they = are slowing down all connections to single-stack networks by xxx ms, making= their users unhappy.

Note that IPv6 has built-in = delays in the protocol itself (DAD for the link-local address; various rand= omized delays) that make it very difficult to get anything done before at l= east 1-2 seconds=C2=A0have passed. Hosts that know that 70% of networks are= IPv4-only will not want to wait 1-2 seconds to connect to those networks.<= /div>
--000000000000089f160598f1539f-- From nobody Thu Dec 5 05:24:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414BD120858; Thu, 5 Dec 2019 05:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Klsol1T01THv; Thu, 5 Dec 2019 05:24:42 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EA1120170; Thu, 5 Dec 2019 05:24:42 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 47TGfH5B7Bz1ydH; Thu, 5 Dec 2019 14:24:39 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 47TGfH26t7zFpX7; Thu, 5 Dec 2019 14:24:39 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 14:24:39 +0100 From: To: Lorenzo Colitti CC: Jen Linkova , =?utf-8?B?QmrDuHJuIE1vcms=?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVq0wM0EzcIgM90k+qjQhPGFF0raerWiog Date: Thu, 5 Dec 2019 13:24:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E4587OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 13:24:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330313E4587OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IGpldWRpIDUg ZMOpY2VtYnJlIDIwMTkgMTA6MTINCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KQ2Mg OiBKZW4gTGlua292YTsgQmrDuHJuIE1vcms7IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlzdDsg ZHJhZnQtbGluay1kaGMtdjZvbmx5QGlldGYub3JnDQpPYmpldCA6IFJlOiBbZGhjd2ddIElQdjYt T25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbg0KDQpPbiBUaHUsIERlYyA1LCAyMDE5IGF0IDU6 NTggUE0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCklNTywgYSBob3N0IHdpbGwgbmVlZCB0byDigJxwYXVz ZeKAnSB0aGUgdjQgY29uZmlndXJhdGlvbiBmb3IgeHh4IG1zIHRvIG1ha2Ugc3VyZSB0aGUgY29u ZmlndXJhdGlvbiAodjQvdjYpIGlzIGNvbnNpc3RlbnQuDQoNCkhvc3RzIGRvIG5vdCBkbyB0aGlz IHRvZGF5LCBhbmQgSSBkb24ndCB0aGluayB0aGV5IHdpbGwgc3RhcnQgZG9pbmcgc28uIFRoZSBy ZWFzb24gaXMgdGhhdCB0aGV5IGNhbm5vdCB0ZWxsIHdoZXRoZXIgYW5vdGhlciBwcm90b2NvbCB3 aWxsIHN0YXJ0IHdvcmtpbmcuIElmIHRoZXkgd2FpdCB4eHggbXMgdG8gbWFrZSBzdXJlIHRoZSBv dGhlciBwcm90b2NvbCBjb21lcyB1cCwgdGhleSBhcmUgc2xvd2luZyBkb3duIGFsbCBjb25uZWN0 aW9ucyB0byBzaW5nbGUtc3RhY2sgbmV0d29ya3MgYnkgeHh4IG1zLCBtYWtpbmcgdGhlaXIgdXNl cnMgdW5oYXBweS4NCg0KW01lZF0gRG8geW91IG1lYW4gdGhhdCBjbGllbnRzIHRoYXQgcmVjZWl2 ZSB0aGUgc2lnbmFsIHRvIHJlbGVhc2UgSVB2NCBjb25maWd1cmF0aW9uIHdpbGwgbWFrZSB0aGUg dXNlcnMgdW5oYXBweSBhbnl3YXkgYmVjYXVzZSB0aGV5IHdpbGwgbmVlZCB0byB3YWl0IGZvciB0 aGUgcHJlZjY0IHRvIHByb3Blcmx5IHdvcms/DQoNCk5vdGUgdGhhdCBJUHY2IGhhcyBidWlsdC1p biBkZWxheXMgaW4gdGhlIHByb3RvY29sIGl0c2VsZiAoREFEIGZvciB0aGUgbGluay1sb2NhbCBh ZGRyZXNzOyB2YXJpb3VzIHJhbmRvbWl6ZWQgZGVsYXlzKSB0aGF0IG1ha2UgaXQgdmVyeSBkaWZm aWN1bHQgdG8gZ2V0IGFueXRoaW5nIGRvbmUgYmVmb3JlIGF0IGxlYXN0IDEtMiBzZWNvbmRzIGhh dmUgcGFzc2VkLiBIb3N0cyB0aGF0IGtub3cgdGhhdCA3MCUgb2YgbmV0d29ya3MgYXJlIElQdjQt b25seSB3aWxsIG5vdCB3YW50IHRvIHdhaXQgMS0yIHNlY29uZHMgdG8gY29ubmVjdCB0byB0aG9z ZSBuZXR3b3Jrcy4NCg0KW01lZF0gSW4gdGhhdCBjYXNlLCB3aGF0IGlzIHRoZSBiZW5lZml0IGZv ciB0aGUgaG9zdCB0byBpbmRpY2F0ZSBpdHMgaXB2Ni1vbmx5IG1vZGUgc3VwcG9ydD8NCg== --_000_787AE7BB302AE849A7480A190F8B9330313E4587OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmUt LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4g amV1ZGkgNSBkw6ljZW1icmUgMjAxOSAxMDoxMjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FE QUlSIE1vaGFtZWQgVEdJL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gSmVuIExpbmtvdmE7IEJq w7hybiBNb3JrOyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3Q7IGRyYWZ0LWxpbmstZGhjLXY2 b25seUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtkaGN3Z10gSVB2Ni1P bmx5IFByZWZlcnJlZCBESENQdjQgb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgRGVjIDUsIDIwMTkgYXQgNTo1OCBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SU1PLCBhIGhvc3Qgd2lsbCBuZWVkIHRvIOKAnHBhdXNl4oCdIHRoZSB2NCBjb25maWd1cmF0 aW9uIGZvciB4eHggbXMgdG8gbWFrZSBzdXJlIHRoZSBjb25maWd1cmF0aW9uICh2NC92NikgaXMN CiBjb25zaXN0ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3N0cyBkbyBub3QgZG8g dGhpcyB0b2RheSwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhleSB3aWxsIHN0YXJ0IGRvaW5nIHNvLiBU aGUgcmVhc29uIGlzIHRoYXQgdGhleSBjYW5ub3QgdGVsbCB3aGV0aGVyIGFub3RoZXIgcHJvdG9j b2wgd2lsbCBzdGFydCB3b3JraW5nLiBJZiB0aGV5IHdhaXQgeHh4IG1zIHRvIG1ha2Ugc3VyZSB0 aGUgb3RoZXIgcHJvdG9jb2wgY29tZXMgdXAsIHRoZXkgYXJlIHNsb3dpbmcgZG93bg0KIGFsbCBj b25uZWN0aW9ucyB0byBzaW5nbGUtc3RhY2sgbmV0d29ya3MgYnkgeHh4IG1zLCBtYWtpbmcgdGhl aXIgdXNlcnMgdW5oYXBweS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltNZWRdDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RG8geW91IG1lYW4gdGhhdCBjbGllbnRzIHRoYXQgcmVjZWl2ZSB0 aGUgc2lnbmFsIHRvIHJlbGVhc2UgSVB2NCBjb25maWd1cmF0aW9uIHdpbGwgbWFrZSB0aGUgdXNl cnMgdW5oYXBweSBhbnl3YXkgYmVjYXVzZSB0aGV5IHdpbGwgbmVlZCB0byB3YWl0IGZvciB0aGUg cHJlZjY0DQogdG8gcHJvcGVybHkgd29yaz8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdGUgdGhhdCBJUHY2IGhhcyBi dWlsdC1pbiBkZWxheXMgaW4gdGhlIHByb3RvY29sIGl0c2VsZiAoREFEIGZvciB0aGUgbGluay1s b2NhbCBhZGRyZXNzOyB2YXJpb3VzIHJhbmRvbWl6ZWQgZGVsYXlzKSB0aGF0IG1ha2UgaXQgdmVy eSBkaWZmaWN1bHQgdG8gZ2V0IGFueXRoaW5nIGRvbmUgYmVmb3JlIGF0IGxlYXN0IDEtMiBzZWNv bmRzJm5ic3A7aGF2ZSBwYXNzZWQuDQo8L3NwYW4+SG9zdHMgdGhhdCBrbm93IHRoYXQgNzAlIG9m IG5ldHdvcmtzIGFyZSBJUHY0LW9ubHkgd2lsbCBub3Qgd2FudCB0byB3YWl0IDEtMiBzZWNvbmRz IHRvIGNvbm5lY3QgdG8gdGhvc2UgbmV0d29ya3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBJbiB0aGF0IGNhc2UsIHdoYXQgaXMgdGhlIGJl bmVmaXQgZm9yIHRoZSBob3N0IHRvIGluZGljYXRlIGl0cyBpcHY2LW9ubHkgbW9kZSBzdXBwb3J0 Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330313E4587OPEXCAUBMA2corp_-- From nobody Thu Dec 5 05:53:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF05120020; Thu, 5 Dec 2019 05:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 ehTyacZcoJhn; Thu, 5 Dec 2019 05:53:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FF7120013; Thu, 5 Dec 2019 05:53:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C75623818F; Thu, 5 Dec 2019 08:50:04 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5D618AAB; Thu, 5 Dec 2019 08:53:43 -0500 (EST) From: Michael Richardson To: Jen Linkova cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List In-Reply-To: References: <28594.1575483729@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 13:53:46 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: > On Thu, Dec 5, 2019 at 5:22 AM Michael Richardson wrote: >> A question that we had was whether or not hosts in a IPv6-mostly network >> should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts. > Actually the more I think about it the more I believe the host should > be doing whatever they are doing w/o DHCPv4 presence. > Android does not configure IPv4 link-locals, MacOS does. Making the > same OS behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server > responded with IPv6-only Preferred option") might be undesirable. As > an operator I'd expect that IPv6-only capable host would behave the > same way on a dedicated IPv6-only segment and on IPv6-mostly segment. I see the logic: that they shouldn't change. I think that a lot of desktop OSes go for IPv4-LL when DHCPv4 fails because their IPv4 logic was written before IPv6 was a thing. I think that if I set up an IPv6-mostly segment it is because I know that there are hosts which speak IPv4 only, or which have IPv4-only applications which do not work through NAT64. (An IPv4-only printer is such an "application") I think that the DHCPv4 option is a clue that configuring IPv4-LL addresses is a good thing. Does Android configure IPv4-LL when it has IPv4? I think that this also varies by the host OS. Having said this, I don't feel strongly about it either way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3pC+cACgkQgItw+93Q 3WXfTQgAsTreVc0zZFyh8m08WhojwmHyfelYEUBxb1wCfKKvg5871WrkyGg8pnrC 90JTnBv32qzqV7DD1VQdmnMcgTvqVcUnjqeIFN2vDgimcOWsHeLRva/yG2LY5l26 lkc70RABIdB5QmcwQJvbmfq9t4GHod185TrLc/J79TUHy6jWBnaIUnQBKwv+aSSk fN2026lIy5Q3qQebSXC8DF/5/LZzsgyaoLmz6tOPcc0u2s+2BL8uqBRpmdADuqil h+QwGkQe/H3Oh3o14KUAfwlLvsarSagV9DV0llcsu0uijWlooTlAGCf47SaCnmIp yjaiUh4iPyxyFS4fn9unQf2PTcw4xA== =YCwU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 5 05:56:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8EF120020; Thu, 5 Dec 2019 05:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 4VeAI2AKPNUv; Thu, 5 Dec 2019 05:56:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A3B120013; Thu, 5 Dec 2019 05:56:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 21E8D3818F; Thu, 5 Dec 2019 08:52:54 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE172AAB; Thu, 5 Dec 2019 08:56:32 -0500 (EST) From: Michael Richardson To: David Farmer cc: Jen Linkova , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org In-Reply-To: References: <28594.1575483729@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 13:56:36 -0000 --=-=-= Content-Type: text/plain David Farmer wrote: Jen> Actually the more I think about it the more I believe the host Jen> should be doing whatever they are doing w/o DHCPv4 presence. Android Jen> does not configure IPv4 link-locals, MacOS does. Making the same OS Jen> behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server Jen> responded with IPv6-only Preferred option") might be undesirable. As Jen> an operator I'd expect that IPv6-only capable host would behave the Jen> same way on a dedicated IPv6-only segment and on IPv6-mostly Jen> segment. > Regarding IPv4-LL, I like Roy Marples suggestion of combining this with RFC > 2563 to determine if a host is to configure an IPv4-LL, and in that case, the > address returned should be 0.0.0.0. I agree. I didn't know that we had 2563 to turn off LL. So hosts should do whatever they want, and if the operator does not want v4LL, then they can turn this on. > Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by a > server "if the IPv6-only Preferred option is present in the Parameter Request > List received from the client and the corresponding DHCP pool is explicitly > configured as belonging to an IPv6-mostly network segment" as discussed in > Section 3.3? I think that we were concerned that stupid hosts might configure it by mistake. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3pDJAACgkQgItw+93Q 3WW0Xgf+LwsohyBrqUbCkWTuovySbsEToFY+QAbmNyz6uWDDL/J/JH3teSwskNcT klXdV78ZJMOwYLS+oG6+12605IxrESYqlmXZm/fh+6hvjs5W3e5mZbDbajCBMHRv q2BGR4gVHIiTWIedumABTK5m2l6z877PkxlTru+Xb9/Tfx0bwU8xLcW/SyNdL5IC vJKA0mnoysQs+X/t4m45jontgd1y+tAFCaTAdkKFLWUtSH9TZeVUwUi5oyeR5Zp7 oEOiK4HvC/SqjWtgbjCe9SIaFQn4q4GcdRCMFlbmnuW/jSGUHD1a18j/swoOrE+t kSEFyb/T3V/6j9hewqQUTGFx4Wh/Lg== =KghF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 5 06:19:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE0120108 for ; Thu, 5 Dec 2019 06:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 BzQpPVR2mO6w for ; Thu, 5 Dec 2019 06:19:00 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993671200C7 for ; Thu, 5 Dec 2019 06:19:00 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id k24so3765709ioc.4 for ; Thu, 05 Dec 2019 06:19:00 -0800 (PST) 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=HS7Q8LDk86K9vCQ1t3BbrmN1sF3DNoI3TUje7dqLY5U=; b=tzffiKlUhFjiIjEB31kpRz1bOvB6pHoMOoppwd/P3powLV8VUYg43TdBLRAvqm4SS+ 8StoJ+rlniXVjh6VxMrjx4lF0JMM1JBAZdtCkoshuDDdwOnC3JpYjkbnyduUlPkgu1c1 sD1tYTddeJSLmaqKatHJFR9phallNMlHdF+wx170SjiHpg4lXgX5vwt1Y6d94mJJsIrT +/XmuA/XviiKR/TqcyBy0wkQeFTPvy88JaKmozLqkQsIbJKZdtHMr7IS4DU2ypFa1Y3y c5AYufrBm4SY9z8cUIkDUcd3xg6T6Y/VOEtS13kkTCMldDVaYpQy+rmPiqzR57gn5yrH fXHw== 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=HS7Q8LDk86K9vCQ1t3BbrmN1sF3DNoI3TUje7dqLY5U=; b=JXH0424pF+pnqDFuvuMv/bEasIOWx1eEk6zw6+vVQIiWe3Cga48aeU2CCHifMJFk+1 SWzjKEVbuXVD9/1MXe7QjX8h8cXavGOzKnCJYBBP+hbgZLvdF7IVNdwcZbKCmN0kA8SL vggjjr0u/xP7fH86O0ewBEjz8QSeInHRs6vKwFyD2xzSn//Z27iO6M1JmMz35c9t9SlS JKH8eHpMIZKtKTK4S89aVj3szB6gDmQHLWuLtJTKW/tu+Qctc6WBv5QaSg2XSrd97JBC HTt/nIT1j4/Nl0tKwshsMMeAYm0gRbzJRaoI465ztVCddb1TgqOt2eIitwq05TARCbOC wBow== X-Gm-Message-State: APjAAAXQ1RKuMz2r7RmNumwua2bZpdKFldRsftYsOMxqZ3qvt7QQHIN0 nv8bnLvVrDSbBI5v+M7Izfht4egdxYcArps8/fbZng== X-Google-Smtp-Source: APXvYqz879UTek9iA7ecTGJESCGn+LIvnFPis5oOCqhT1jRYtrmjWCnehB/k391rvYcmXXpohG1PnGVciYSXk3wOrSs= X-Received: by 2002:a5d:81d4:: with SMTP id t20mr6809699iol.170.1575555539616; Thu, 05 Dec 2019 06:18:59 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 23:18:47 +0900 Message-ID: To: "" Cc: Jen Linkova , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Content-Type: multipart/alternative; boundary="00000000000043ba480598f59c04" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:19:02 -0000 --00000000000043ba480598f59c04 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 10:24 PM wrote: > Hosts do not do this today, and I don't think they will start doing so. > The reason is that they cannot tell whether another protocol will start > working. If they wait xxx ms to make sure the other protocol comes up, they > are slowing down all connections to single-stack networks by xxx ms, making > their users unhappy. > > > > *[Med] *Do you mean that clients that receive the signal to release IPv4 > configuration will make the users unhappy anyway because they will need to > wait for the pref64 to properly work? > Well, that's the intent of the pref64 RA option. That allows the pref64 to be communicated in the same packet as the rest of the configuration parameters. > Note that IPv6 has built-in delays in the protocol itself (DAD for the > link-local address; various randomized delays) that make it very difficult > to get anything done before at least 1-2 seconds have passed. Hosts that > know that 70% of networks are IPv4-only will not want to wait 1-2 seconds > to connect to those networks. > > > > [Med] In that case, what is the benefit for the host to indicate its > ipv6-only mode support? > The option improves the situation by allowing the host to wait for IPv6 only if it is expected to exist. Hosts that implement the option allow networks to provide better service and create an incentive for networks to support IPv6, which is good for everybody in the long term. --00000000000043ba480598f59c04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 10:24 PM <mohamed.boucadair@orange.com= > wrote:

H= osts do not do this today, and I don't think they will start doing so. = The reason is that they cannot tell whether another protocol will start wor= king. If they wait xxx ms to make sure the other protocol comes up, they ar= e slowing down all connections to single-stack networks by xxx ms, making their users unh= appy.

=C2=A0

[Med] Do you mean that clients that re= ceive the signal to release IPv4 configuration will make the users unhappy = anyway because they will need to wait for the pref64 to properly work?

=
Well, that's the intent of the pref64 RA option. That al= lows the pref64 to be communicated in the same packet as the rest of the co= nfiguration parameters.
=C2=A0

Note that IPv6 has built-in del= ays in the protocol itself (DAD for the link-local address; various randomi= zed delays) that make it very difficult to get anything done before at leas= t 1-2 seconds=C2=A0have passed. Hosts that know that 70% of networks are IPv4-only will not want to = wait 1-2 seconds to connect to those networks.

=C2=A0

[Med] In that case, what= is the benefit for the host to indicate its ipv6-only mode support?=


The option imp= roves the situation by allowing the host to wait for IPv6 only if it is exp= ected to exist. Hosts that implement the option allow networks to provide b= etter service and create an incentive for networks to support IPv6, which i= s good for everybody in the long term.
--00000000000043ba480598f59c04-- From nobody Thu Dec 5 06:20:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00F1200C7 for ; Thu, 5 Dec 2019 06:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 gZTSV6YnZp7o for ; Thu, 5 Dec 2019 06:20:35 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3D9120104 for ; Thu, 5 Dec 2019 06:20:35 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id g12so3149154ild.2 for ; Thu, 05 Dec 2019 06:20:35 -0800 (PST) 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=2nAQtBeJ5wxHDeHVLJksftBpW+VcMkQV3w3BQbw/DyA=; b=rL0R9V8X42jkI90+17iKYMzTufq/OBcMzeWeM1DLNgECV+pMhWF808Y7/Z9l2z/BXZ 66DcwxDYSNJumEESTw4z9RXobBXwLx6ui41HmUXAxFxk88GW88Wx/JOl2XeJxem3Gyrj UMWUnW7vehUip7GhsXBtXDDjsgV7gbEwY7XIEZ9eR+KzrGEVhpjyRSZCarH/YvsMnuqO E3AsKWmIuccD/sRVk2mlY1bbEwIyXxKpX4riCpEW1AJNxRVD8+JbAIAsKrm3jxTUOMZL ML+2Xre6eOFeEl93p+R1ZVypZ0mDA+FjTYq7K374XPo+sSnJoynpf5TDbGX9xU08Rn8f D0cQ== 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=2nAQtBeJ5wxHDeHVLJksftBpW+VcMkQV3w3BQbw/DyA=; b=oIjlt9/42F2MD15kEuIvkbWCKArJsi7XGZgjlpZy8ACD9ybaMPLTSb+oYNkRHfxcRg MAyyyJ9NRuEl9fOBEwlhGHp8In99BRiTFDG9KJzITToRBcHJS9N9Gcr49jBDCA5WSZuj wDIiNaPFXuqV0TACPnl+ZBQ+KaU4iHhBvYkWKKZlEIBWEax/d7qkns4C0PiEAtjCE6JY FuDUQdZ7le/NSKaszt61p3fpZvv6x4Mu4z0FW2QhvUJoZGnlmeVdf08+uBZWeTQ6dCGj oT21E9G+ms5lyxmk69aNqclcS1UNS234OlRo9P5gStvcx9T7RCArERuhj9PPkUEWX7zf kWIQ== X-Gm-Message-State: APjAAAUu5TDjzVjCntDTKRnZA9EuKBoyB9+tWtdvhUEsHzrpERUhNlYw uU6/1YZeSiq8w4fpj1mNYEGVmwz6ysN3+JDs8dZTiA== X-Google-Smtp-Source: APXvYqy0KzHV1DDh74Melu9JumEdod9KDdF6+UOoag5HReRxQ1LN1QrlXGGtjLQy2XHDlqeodJnjciL21Ik6vOAgwm8= X-Received: by 2002:a92:ba93:: with SMTP id t19mr9550717ill.0.1575555634118; Thu, 05 Dec 2019 06:20:34 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <15674.1575554023@localhost> In-Reply-To: <15674.1575554023@localhost> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 23:20:22 +0900 Message-ID: To: Michael Richardson Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000e5e30b0598f5a189" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:20:37 -0000 --000000000000e5e30b0598f5a189 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 10:53 PM Michael Richardson wrote: > I think that the DHCPv4 option is a clue that configuring IPv4-LL addresses > is a good thing. Does Android configure IPv4-LL when it has IPv4? I > think > that this also varies by the host OS. > Stock Android does not support IPv4-LL. --000000000000e5e30b0598f5a189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 10:53 PM Michael R= ichardson <mcr+ietf@sandelman= .ca> wrote:
I think that the DHCPv4 option is a clue that= configuring IPv4-LL addresses
is a good thing.=C2=A0 =C2=A0Does Android configure IPv4-LL when it has IPv= 4?=C2=A0 I think
that this also varies by the host OS.

S= tock Android does not support IPv4-LL.
--000000000000e5e30b0598f5a189-- From nobody Thu Dec 5 06:22:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FF4120105 for ; Thu, 5 Dec 2019 06:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 73W3Z_4-r0re for ; Thu, 5 Dec 2019 06:22:11 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF381120013 for ; Thu, 5 Dec 2019 06:22:11 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id g12so3154116ild.2 for ; Thu, 05 Dec 2019 06:22:11 -0800 (PST) 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=+BvBnrqsJ1PsMSOIdD6uKQYRnk+c5zq9qzzBQQPpj70=; b=d7nVxjWBA8V4xgyFEbuotnPYnIdXj1960Una/DhNjvdeIdhgN7unu5EutHOyipgX3f HPz0fZqB5RQFWjM/+sECnawNj4rhHQJzdB8XwS+B+f//lZX4m9b+KJmCF2NBAsuG4ghU vkXjIb9TEkkE4D63Ofca3AiZDJLcyeELzgLQHc5hCyPevYnecwIlhX+oSxIxKGqz6QYW 2UyJetyXiZbc/O1UA3m9jLM7q8/tjfwhtPmg1rxJd3eKDTPyx56EWQsWWpcgeDpH1r/I n5rbKpd8yzMoMG+6vU4ZLdGY2aCd3sO4fYuDxdidvi/NkqGQB8kX8FQbU9aXguxN/CoY Ea9A== 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=+BvBnrqsJ1PsMSOIdD6uKQYRnk+c5zq9qzzBQQPpj70=; b=h/cJyS21xX5ZAsNXs7URv6P2ywjUy2cuXyVY5j2DVrlwtp+gQ4gM7fnz+ZbaSaIZ8b xAznn7invJKP5JgpbNmino0loQrmX5OzNnXQbq4iYcMc7AvQS06yhGwG0YrZ3E7bxJ09 6jx1ROqI2++n6d3JOIgGH9wxZxtON+Iow2GdghTECnXBDUkfxRLkkLEv6Yj2UBE1u8wQ DjFVhB5sPxzeHUpw1D67tJNNGvad5KiH9fFlJ8otgX3pGc6rufWpAM09IeW8WAFlNDJ7 NMQ/BFETZFR+Df042fIuqgwgzEW2aZV7HOzo649UPDtfrDhaiQEXPcBx2P0MkzLcC7Mx sa2A== X-Gm-Message-State: APjAAAXl7BUsHkoycgypTHnLkFSIZ4v21kDwO6E8KVLQUXGsk7gW3Ir9 Pgh2qDfs2fiQE/jdjcYKRIJhVl86wrTwslYmTvPXUA== X-Google-Smtp-Source: APXvYqx3WyTfetWhDLLNIsjTSwzrLlfNEXStvuRyJwvs2Doyzw69uHFsJsfIzVwL5H0PJOe9m5h49lty6Raj0XfJiB0= X-Received: by 2002:a92:6e09:: with SMTP id j9mr6542320ilc.178.1575555730978; Thu, 05 Dec 2019 06:22:10 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <16245.1575554192@localhost> In-Reply-To: <16245.1575554192@localhost> From: Lorenzo Colitti Date: Thu, 5 Dec 2019 23:21:59 +0900 Message-ID: To: Michael Richardson Cc: David Farmer , Jen Linkova , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: multipart/alternative; boundary="000000000000ab9a3c0598f5a7f8" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:22:14 -0000 --000000000000ab9a3c0598f5a7f8 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 10:56 PM Michael Richardson wrote: > > Regarding IPv4-LL, I like Roy Marples suggestion of combining this > with RFC > > 2563 to determine if a host is to configure an IPv4-LL, and in that > case, the > > address returned should be 0.0.0.0. > > I agree. > I didn't know that we had 2563 to turn off LL. > So hosts should do whatever they want, and if the operator does not want > v4LL, then they can turn this on. > Do any popular operating systems implement RFC 2563? > > Also, is there any reason that 0.0.0.0 shouldn't be the address > retunded by a > > server "if the IPv6-only Preferred option is present in the > Parameter Request > > List received from the client and the corresponding DHCP pool is > explicitly > > configured as belonging to an IPv6-mostly network segment" as > discussed in > > Section 3.3? > > I think that we were concerned that stupid hosts might configure it by > mistake. > That, or that DHCP relays or snooping switches might get confused. --000000000000ab9a3c0598f5a7f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 10:56 PM Michael R= ichardson <mcr+ietf@sandelman= .ca> wrote:
=C2=A0 =C2=A0 > Regarding IPv4-LL, I like = Roy Marples suggestion of combining this with RFC
=C2=A0 =C2=A0 > 2563 to determine if a host is to configure an IPv4-LL, = and in that case, the
=C2=A0 =C2=A0 > address returned should be 0.0.0.0.

I agree.
I didn't know that we had 2563 to turn off LL.
So hosts should do whatever they want, and if the operator does not want v4LL, then they can turn this on.

Do an= y popular operating systems implement RFC 2563?
=C2=A0
=C2=A0 =C2=A0 > Also, is there any reason that 0.0.0.0 shouldn't be = the address retunded by a
=C2=A0 =C2=A0 > server "if the IPv6-only Preferred option is presen= t in the Parameter Request
=C2=A0 =C2=A0 > List received from the client and the corresponding DHCP= pool is explicitly
=C2=A0 =C2=A0 > configured as belonging to an IPv6-mostly network segmen= t" as discussed in
=C2=A0 =C2=A0 > Section 3.3?

I think that we were concerned that stupid hosts might configure it by
mistake.

That, or that DHCP relays or s= nooping switches might get confused.
--000000000000ab9a3c0598f5a7f8-- From nobody Thu Dec 5 06:39:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1182120013 for ; Thu, 5 Dec 2019 06:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CzOAcV8Jc6eJ for ; Thu, 5 Dec 2019 06:39:21 -0800 (PST) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8F3120019 for ; Thu, 5 Dec 2019 06:39:21 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id y206so1731192pfb.0 for ; Thu, 05 Dec 2019 06:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=FjCoC9s2ONRttEaQ/vMssvwKAiDaTOBwfKGao+fePew=; b=lA/No6AzpWH55C+Fh5l8gqYv21BgpjdmtBCTXJ1DGuMObA1v0rRYp1JYHnJeJNYq+R neq9FVIEAH6B2w2bn3G4mVh+ulSk9qAQZtGwwRWOZPUdmJeuxBb+D1+2bcqtYQTnFdgW AM1tU/S0KXVrFj0uPycSrduFQXg3iLs4nlEzB8e0oUCKH+ALlQZVHYoOniMpfxhU6Jgr XfB5k7UbxWLpKgbPPj77IKtg4C+zTf4zOf0L7AHbrY1Bq2Y5jS45wY2YRP0UsYlh5wg1 x5NeQ7atJmSTw3ORMiC0/FmNT4wssGxfTeIk0YObkYh0rKE89rVfIdNIaFstko2I5Yza Nwtw== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=FjCoC9s2ONRttEaQ/vMssvwKAiDaTOBwfKGao+fePew=; b=Jo1467HOvBAArOe3MQzj+ypDWvbeEtz1CTx+qKuh4mFiH+yVrOfMnm67afk5Z9iLR9 SsDnjDpeLOl3nWrS01DSNr+IXOkxTd0ZviSvBTmi4jkEg2AiXofIX73Ujc/ZANSXX12N F4GN2xdEY3nrNvW484jel8sZlBR7ai9SpF9ylZbuDQMY6wxlmJSHYq3R/qz32lhZt8et B2VwjkeZhHDIoXPs111+TZBxL2dGHP1hZPjs2ViZAk9MJUw7qDsbV3O5Og/GIXiKi6TO T0ISbYiVLGPLy8D0qB4jIbDoAPn4qFmTJer0WqhLRnP4vU21VrpqyqPmuiNKRM9WNJNO elqQ== X-Gm-Message-State: APjAAAVU9bPEDGy5z05xNO9vhzUd9Q7uYe9Kdcycr0smgtDyJ+X5OU1x KeSyQ8ec0CnKEHgfbvl8IGxrdA== X-Google-Smtp-Source: APXvYqyc4uYE7llg0EaVsPLwxv1Om5WPO6KBRAnVDkZfLR3nM9iIH4ILcchXVYeVrlvG5OlQkJgxkg== X-Received: by 2002:a63:cf09:: with SMTP id j9mr9417376pgg.393.1575556760714; Thu, 05 Dec 2019 06:39:20 -0800 (PST) Received: from [10.20.1.77] (ip-64-134-236-149.public.wayport.net. [64.134.236.149]) by smtp.gmail.com with ESMTPSA id e11sm4049pjj.26.2019.12.05.06.39.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2019 06:39:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 5 Dec 2019 06:39:18 -0800 Message-Id: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com> References: Cc: Lorenzo Colitti , Tomek Mrugalski , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org In-Reply-To: To: Roy Marples X-Mailer: iPad Mail (17E177) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:39:24 -0000 On Dec 4, 2019, at 8:46 PM, Roy Marples wrote: > So in simple terms. > The server offers some information. > Given this information (in current DHCP semantics) we can RENEW (T1) or RE= BIND (T2). > If the client does not request the offer (hey! I see this new fangled opti= on here that says NO DHCP) the client can still accept the T2 timer at the v= ery least. >=20 > Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX= _RT and INF_MAX_RT. This RFC goes out of its way not to add new timers. There is a reason why DHCP includes a parameter request list option. If the= client doesn=E2=80=99t ask for this newfangled option, it shouldn=E2=80=99t= see it. And so we can know for sure that the client supports this capabili= ty, because it asked for it. Is there any reason why we /wouldn=E2=80=99t/ want to do this? From nobody Thu Dec 5 06:48:12 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DAB12004F for ; Thu, 5 Dec 2019 06:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_IFdv6raeAK for ; Thu, 5 Dec 2019 06:48:06 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [77.68.23.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 F2A71120019 for ; Thu, 5 Dec 2019 06:48:05 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 8D84379B for ; Thu, 5 Dec 2019 14:48:03 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id F0F121CD5DA; Thu, 5 Dec 2019 14:47:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575557224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=liLiXgXnqpwpjvxsTWMYCgQCELQWyqzDf0Y8FoLDjTg=; b=PLTQBxmR0INwC8lkIajS7Px4AD4y/qH2bQGSkeeGEDYHPpLF8lRGArCrjKvAaG4NH8ydts 4U5HJDmSLDNVvJHOXHSzMMNcIB6pNqu2ZobuCKn/bPEClLJeGbXdKqgiiHOY7z1gbdBPan +kJbe3mWx7vdJrXerAr1VYOFi1hpzxM= To: Ted Lemon Cc: Lorenzo Colitti , Tomek Mrugalski , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org References: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com> From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 14:47:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 14:48:07 -0000 On 05/12/2019 14:39, Ted Lemon wrote: > On Dec 4, 2019, at 8:46 PM, Roy Marples wrote: >> So in simple terms. >> The server offers some information. >> Given this information (in current DHCP semantics) we can RENEW (T1) or REBIND (T2). >> If the client does not request the offer (hey! I see this new fangled option here that says NO DHCP) the client can still accept the T2 timer at the very least. >> >> Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new timers. > > There is a reason why DHCP includes a parameter request list option. If the client doesn’t ask for this newfangled option, it shouldn’t see it. And so we can know for sure that the client supports this capability, because it asked for it. > > Is there any reason why we /wouldn’t/ want to do this? None at all. I think it's a good option to have, but I strongly believe it should just be a boolean on/off option. The host should be as dumb as possible. If the server knows *something* else is around that it should use instead it can disable DHCP via this option. The *something* else is probably IPv6 but I don't see why this RFC should mention it other than a use case. Roy From nobody Thu Dec 5 07:01:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201B212002E for ; Thu, 5 Dec 2019 07:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zJIrfouc18m for ; Thu, 5 Dec 2019 07:01:01 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1306F120013 for ; Thu, 5 Dec 2019 07:01:01 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id 84DF4797 for ; Thu, 5 Dec 2019 15:00:57 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 2AD0C1CD5DA; Thu, 5 Dec 2019 14:59:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575557998; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y3VbxraWcgl0vTR5BiESzh+iPZyHCg2VNVCPWoANslY=; b=T6b7Wx+Fh/HVSMwnIZdX/MEKveXJlB6PN4JEdZqyuSdh/Y6Rc1tcq6Vj8fWGoqpfFkrW/E khciop419jzGPzlwNJxcIM/xvMvLBld1GoBDxMqVLqozdgdoYXPm0q7f1w9i0KfH6iihDy +upNxsV8H5V4F7tZoBViuGX1yS97DFE= To: Lorenzo Colitti , "" Cc: "dhcwg@ietf.org" , V6 Ops List , =?UTF-8?Q?Bj=c3=b8rn_Mork?= , "draft-link-dhc-v6only@ietf.org" References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Roy Marples Message-ID: Date: Thu, 5 Dec 2019 15:00:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 15:01:02 -0000 On 05/12/2019 09:11, Lorenzo Colitti wrote: > Note that IPv6 has built-in delays in the protocol itself (DAD for the > link-local address; various randomized delays) that make it very > difficult to get anything done before at least 1-2 seconds have passed. > Hosts that know that 70% of networks are IPv4-only will not want to wait > 1-2 seconds to connect to those networks. IPv4 has built in delays as well. DHCP delay randomisation and DAD timings via RFC 5227. NetBSD has RFC 5227 in the kernel and works very nicely. I once saw a PDF that claimed Solaris does the same, although my hands on experience says if it does work it uses timings different from the RFC. Roy From nobody Thu Dec 5 07:12:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64EB12004F for ; Thu, 5 Dec 2019 07:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 WU6l6MKm0zk8 for ; Thu, 5 Dec 2019 07:11:54 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF44F12002E for ; Thu, 5 Dec 2019 07:11:54 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id k24so3966016ioc.4 for ; Thu, 05 Dec 2019 07:11:54 -0800 (PST) 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=k85bYZWn8EzZvkKw8+RmDNUQT1/f+d0oN9jovu+8xcM=; b=JFgMMMnVBMxjR35x+9tdBJm2tbcjf6/h3fS4mytkOkb/d+LRVbK/IZhGOMQ1SYLIEr ed5cDiF37u5Wt2HUEOk86yM1wZdSjU6h4jwNpsZXgthAGUg3saG3gcxm04VDV1Aso2Sd /fsLMZhqwnG7NyQm5tOCSTEsunyc8DSbioS8U4L/QAvePS822kgLM6Hl5CYib/t6GV/o xcEQuVqp9zKg++axmVDUEaMHsV/wxa0AbpnUzaJuvwh1rqCZEq9efzvDFS6aPogdG5q1 y1WYib1Sya1yXLlTcsmLOZLwMOZBlM/zt4qP1n5n/ywP11R7La6YMRtU0KBtDBVbY+Mm dKVQ== 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=k85bYZWn8EzZvkKw8+RmDNUQT1/f+d0oN9jovu+8xcM=; b=VuWYKoRphTAT9Vz7ydl2WF3+9JFKzIqvdjbC+HkZlLjNM+77sKZUjsHb73ymyMfZ8d h3QEdKNpHZ/8yEsFHVwPZipWA9UoIiemH2gOnqteU7kIp6+4nXeIfUzCwh5PMEx8VFtu +G59WzGvaYGLhA/RLfkWTeXyrr0KHc9Q+fTag6xpMVVfhBYTudYbMvE78liL0C/L6pPI LaOJBiKOL4hGbzHBgIs+nyqY2/kRME8WSPRIMYNH5XkWX/7NAuPxH5au+/MGklMJ05H1 EpZIKuvvQ/1RvYMF3XGrVvYqkJzhE9JX+q0jHI88OBBmNQaUcVOhV12+sZFMCujnVRmw aehw== X-Gm-Message-State: APjAAAWNXf0tvBf0kd/aQ/++a1PEyYJH6UxC5YdMZ6ojMkQ57zgumKWn /r6xzRUZL96EB6tRpSic7gyKWNEpq2s9s/jkyFCzwQ== X-Google-Smtp-Source: APXvYqxbJAKuVmUF5zFq7nHD9rYL2FICfn9CLL7S40wQgrlkyFfzZZFNwKZCpQKCbgTYP+X3UQ9mnNuGeiXQabNf8ww= X-Received: by 2002:a6b:9357:: with SMTP id v84mr6758759iod.241.1575558713798; Thu, 05 Dec 2019 07:11:53 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: From: Lorenzo Colitti Date: Fri, 6 Dec 2019 00:11:41 +0900 Message-ID: To: Roy Marples Cc: "" , "dhcwg@ietf.org" , V6 Ops List , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "draft-link-dhc-v6only@ietf.org" Content-Type: multipart/alternative; boundary="00000000000075f5b20598f659d1" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 15:11:57 -0000 --00000000000075f5b20598f659d1 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 6, 2019 at 12:01 AM Roy Marples wrote: > IPv4 has built in delays as well. DHCP delay randomisation and DAD > timings via RFC 5227. > NetBSD has RFC 5227 in the kernel and works very nicely. > True. Coincidentally, we've actually been finalizing an implementation in the last few weeks. The current client just sends a DISCOVER as soon as it possibly can and takes the first offer it gets. > I once saw a PDF that claimed Solaris does the same, although my hands > on experience says if it does work it uses timings different from the RFC. > IIRC we found the RFC timings to be way too long for mobile devices that move between networks often, so we lowered them. --00000000000075f5b20598f659d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 6, 2019 at 12:01 AM Roy Marpl= es <roy=3D40marples.nam= e@dmarc.ietf.org> wrote:
IPv4 has built in delays as well= . DHCP delay randomisation and DAD
timings via RFC 5227.
NetBSD has RFC 5227 in the kernel and works very nicely.

True. Coincidentally, we've actually been finalizing = an implementation=C2=A0in the last few week= s. The current client just sends a DISCOVER as soon as it possibly can and = takes the first offer it gets.
=C2=A0
I once saw a PDF that claimed Solaris does the = same, although my hands
on experience says if it does work it uses timings different from the RFC.<= br>

IIRC we found the RFC timings to be way= too long for mobile devices that move between networks often, so we lowere= d them.
--00000000000075f5b20598f659d1-- From nobody Thu Dec 5 07:13:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30A012002E for ; Thu, 5 Dec 2019 07:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marples.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3IWDoLHfCTt for ; Thu, 5 Dec 2019 07:13:39 -0800 (PST) Received: from relay2.marples.name (relay2.marples.name [IPv6:2a00:da00:1800:80d6::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD02120025 for ; Thu, 5 Dec 2019 07:13:39 -0800 (PST) Received: from mail.marples.name (cpc115040-bour7-2-0-cust370.15-1.cable.virginm.net [81.108.15.115]) by relay2.marples.name (Postfix) with ESMTPS id DC86879B for ; Thu, 5 Dec 2019 15:13:37 +0000 (UTC) Received: from [10.73.1.30] (unknown [10.73.1.30]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 9E7821CD5DA; Thu, 5 Dec 2019 15:12:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marples.name; s=mail; t=1575558757; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UAbQFsqWJyu7j0Y+A1//kUarPhGp7u2W6VgOUEk+010=; b=QuQvxANNMdOdDXRP5Gf2RyxJVsLgxMfu9dJlTNKkWbJs9FZiHOf/ebTvQYU3vnLG6AIaPq WK8NctEaa3d0ObAJ4AnApImr7pBqwuC6OO9a+17Y3AeGh+jZ8Ew6lygXDFcYEW4noY9Vu9 MMr31QD4KzdExrH0uYT6NtwOAsGAcp4= To: Lorenzo Colitti Cc: "" , "dhcwg@ietf.org" , V6 Ops List , =?UTF-8?Q?Bj=c3=b8rn_Mork?= , "draft-link-dhc-v6only@ietf.org" References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Roy Marples Message-ID: <4ebbee15-e3f6-356c-3bb7-53f005dbc162@marples.name> Date: Thu, 5 Dec 2019 15:13:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 15:13:41 -0000 On 05/12/2019 15:11, Lorenzo Colitti wrote: > On Fri, Dec 6, 2019 at 12:01 AM Roy Marples > > wrote: > > IPv4 has built in delays as well.. DHCP delay randomisation and DAD > timings via RFC 5227. > NetBSD has RFC 5227 in the kernel and works very nicely. > > > True. Coincidentally, we've actually been finalizing an implementation >  in > the last few weeks. The current client just sends a DISCOVER as soon as > it possibly can and takes the first offer it gets. > > I once saw a PDF that claimed Solaris does the same, although my hands > on experience says if it does work it uses timings different from > the RFC. > > > IIRC we found the RFC timings to be way too long for mobile devices that > move between networks often, so we lowered them. I would be supportive of an RFC to bring the timings/number of probes in line with IPv6 DAD as well. Roy From nobody Thu Dec 5 08:17:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A748C12007C for ; Thu, 5 Dec 2019 08:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w_Z7ouI9Bwn for ; Thu, 5 Dec 2019 08:16:58 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9D812006D for ; Thu, 5 Dec 2019 08:16:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 58B691BC4D for ; Thu, 5 Dec 2019 16:16:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Hobson In-Reply-To: Date: Thu, 5 Dec 2019 16:16:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <73509531-D012-49E2-8F82-D5A0659E61D4@thehobsons.co.uk> References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> To: v6ops list X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 16:17:01 -0000 Another typo, I think. Top of page 2 it says : "Therefore it would be beneficial for IPv6 deployment if operators could = implement IPv4-mostly (or IPv4-as-a-Service) segments ..." Should that be IPv6-mostly ? Roy Marples wrote: > It assumes that IPv6 is the be-all and end-all. It is, for all practical purposes. > Maybe one day we will have IPv8? Many people said "why go to so many bits for IPv6 addresses ?". The = answer being (partly) so that the need for another mass migration should = be a long long looooong time away - most likely long after all of us are = no longer interested, and IPv4 is as common as AppleTalk, IPX, DECNet, = etc ! > Mark Smith wrote: > So I haven't read the draft either, although the following applied in = the context of the the IPv6-only flag draft and I think this one. >=20 > Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first = application opens an IPv4 (or IPv6) socket, and then released when the = last application closes the last IPv4 socket? Just think about it. An application starts, and wants to know what protocols it can use - it = can't unless something else has forced addresses to be assigned. Or it needs to know what addresses are available (perhaps it's = configured to use only certain addresses) - it can't unless something = has forced them to be assigned. The host (or administrator of it) may wish to apply firewall rules - bit = tricky if there's no protocols active ! When starting an application, the user would have a further delay while = an address was obtained and configured. And what address family would = the system configure ? Would it do the initial DNS request to the IPv4 = server it gets from the DHCP4 server ? Or would it send it to the IPv6 = server it gets from RAs ? Would it wait for "long enough" to know what = address families are available, or just use the first that came up ? What about Bonjour/mDNS/Zeroconf ? Would you suppress them until needed = ? How would another device connect to a service offered on this host if = you suppressed configuring interface(s) and sending mDNS advertisements = until something local needed it ? In reality, most systems (as a whole, taking into account everything = running on them) are so chatty that the host would be forced to obtain = and configure addresses of all families on all interfaces pretty well as = soon as it's started up. Simon From nobody Thu Dec 5 14:26:22 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ABB120168 for ; Thu, 5 Dec 2019 14:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5hruxGJyGVR for ; Thu, 5 Dec 2019 14:26:20 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544261200EF for ; Thu, 5 Dec 2019 14:26:20 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id j5so5112552qtq.9 for ; Thu, 05 Dec 2019 14:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1flWmiutPmXtgXKSDAzkyxEpXsyXEjkImDWstr5fpVg=; b=h0tYkUx/sKns4FA/r2zdQsAr8Lm771XxZDwahIJetCyr7DOzLTHrR1GjGfbNNieYcD CuVVFMVGWyjHtfJ0/cTuFwGu0Sq69pJ2QUI1A4kA3IRuwMgi+/2Gi/S2oLKGc0l21oUD nawMpgg9bYMOb7zLqs2eHPsuuZYHLkVmrq6gG4RPMbDpNlye6SiktxFgwzgge1PJP0WY ihpTx2DtIvHM1+TxqNLp1ChjeRhPAhiXh9laCvpZuptPhIX6qJMRh5UtAsHV2RzlsQut +NXw/y/etgTrkNIZAvfw9xt03/FNKC2Gmv/mx2UNoR8+H4pEbeEcuGq5ha8cf3E5DKiy NGUg== 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=1flWmiutPmXtgXKSDAzkyxEpXsyXEjkImDWstr5fpVg=; b=TPHEhRNL3XanEy8oZ49t+oDuvAh/SonbAWnzmhkm+olK2ZIl93qv0AmjhLX8Peg442 jZGyFlL6nSoxLmZ7vctaM9qWocABAZNgp8PtPh5tBM+unOZ6hp7UOI/b+ZG6uCJhwFuQ K2qg+0UA4F+PU3WNYHb/7z+D3IbF2Wzrz9eSDT6WSu3f/us0tb6BACiafpI6JfvzsKKF T7bS06GfB6eyF6vcLr2+KikbMIp1C0ZYTnMn5SbT8aawAKs8QN9KysDKJHVH71D804bt J4qjUiZglW7sYgTt1Ylr7BgbiYsCj6tNgqYzt8M85NgmDlk8l8zBhUKsWpyD93wmqgPi jHaw== X-Gm-Message-State: APjAAAV+R6QRhPIBvutWloViYAxqL59p02awOE7hnNaAtgzPeltbuK4Z tdhEsAQv8a8nM28TyxG7uUVuD++QFRwXMbHJqIN2iPR0 X-Google-Smtp-Source: APXvYqwGfI2E4xB5ADBbl9nXcGBY30afgaFeYOKTVZsXF4rDiqvyKoeT7bxBIXe3FjYsDdPcssGnS7wtxPXMTZT4hAs= X-Received: by 2002:ac8:244f:: with SMTP id d15mr10145328qtd.149.1575584779206; Thu, 05 Dec 2019 14:26:19 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-Reply-To: From: Jen Linkova Date: Fri, 6 Dec 2019 09:26:07 +1100 Message-ID: To: Philip Homburg Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 22:26:21 -0000 On Thu, Dec 5, 2019 at 7:43 PM Philip Homburg wrote: > I think this draft has different issues. The authors would be happy to work on getting them fixed if you could elaborate on what those issues are ;) > The good thing about this draft is that it doesn't affect legacy networks or > legacy hosts. It also doesn't affect any host that doesn't implement this > draft. > > The good thing about this mechanism is that it is the DHCP server that decides > what to do. Given that the DHCP servers hand out IPv4 addresses, we already > need to trust the DHCP server. So this draft clearly put functionality > where it belongs. > > I'm not sure that it makes sense for an operator to implement this draft. I'm an operator who could not wait to implement that draft (and I'm aware of at least one other operator who might be interested). Maybe I'm not creative enough but all other options of incremental deployment of IPv6-only I've come up with are much more ugly (doubling the number of SSIDs/VLANs or having a portal when users have to request IPv4 so their MACs are whitelisted etc). > Though I have to admit, this draft could finally end the discusion on > whether the default SSID on a meeting network should be NAT64 or dual stack. > With this option it would be upto the host to pick the right way of doing > IPv4. Exactly! Wouldn't it be awesome? ;) -- SY, Jen Linkova aka Furry From nobody Thu Dec 5 15:40:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430A312004E for ; Thu, 5 Dec 2019 15:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wBpmN3smyLT for ; Thu, 5 Dec 2019 15:39:57 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FB9120033 for ; Thu, 5 Dec 2019 15:39:57 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id b137so2324466pga.6 for ; Thu, 05 Dec 2019 15:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=gyN1/gKC1e1AUkHfNYiDRYG3RYU6vrecgKGKjSewCtY=; b=JGWIQT1bwj7bbbXsSLMWGROPJu6bbqvm8dMkM7Gu53C5q4e6bJSqDut2NbrNxJxfIB cRQ1Kp2Ftb3RlJX4Rp5xNoF3VGl4OC+0z5VVwSX1a4RR6jhRl4whg/xgNfts8E91uD+b 5Wi2tLgCBUGxUnkrrSifqvgDXtNfVlWH+h1WrxlQ9GJQWRH7EGoCZF2sK3ofXM5XtuY8 71VecdR0b9X0EqPrIlipb8TQD+9bZmH8GKNYIIrgMiUfPdyOolv6X97uFjs0xKyGACq8 rS40o0qYPq6ZdTqlCV4id0Jl6I+XUQqQq6jmFPCBR/Dg1lLqSFhSabslX0/7IQrUg1YN EbAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=gyN1/gKC1e1AUkHfNYiDRYG3RYU6vrecgKGKjSewCtY=; b=Qn+tOwc414gwCQy7Hvd0Dlr2rgdCdG0zdAptEiib3opcJC7ZjdavTaxKeztenc19to 1vsKLOMsX7GqooE3M4taYNmPxIZrVEU2PYFdI1voUX7UHluPBrkdFDzssyF0IWidWJM1 1KhTf+pjzsWTRqD9a6uN84Ou1Xii3XHnHfCQrugbiPiDxCOLvRIYrHyrYEaqZpls/vnY tF9s1QJUQ++gpKfQParC4xG/DOkd5Q+98s5Dm/gRngpesdA+yB/cO2RuLZf2X+2iIlUE xQ9APbMwxz4LbRJRc0h9kB1IurU3d/4eeQRWoNcuO80lhz0P0EdaKtzyeJ5iTT9s6Fq2 RfQg== X-Gm-Message-State: APjAAAUWXlfGE1JB+cO5kE3G0TlGI/h2F217kOkYRYcesoLp5ppnmKzL f3KQVtAzQQ18h/nQ31liXGnnu6gx X-Google-Smtp-Source: APXvYqySsXxCOhKn+xqke0gLN9pOcrM9xql/QFxTL2FT+APy3uO+eXtbhYRFcZEUhIxglcJDIhWlcA== X-Received: by 2002:aa7:9198:: with SMTP id x24mr11966822pfa.203.1575589196619; Thu, 05 Dec 2019 15:39:56 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::100c? ([2600:8802:5900:13c4::100c]) by smtp.gmail.com with ESMTPSA id r193sm8305372pfr.100.2019.12.05.15.39.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2019 15:39:55 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: Date: Thu, 5 Dec 2019 15:39:52 -0800 To: V6 Ops List X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [v6ops] A few thoughts on draft-smith-v6ops-local-only-addressing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 23:39:59 -0000 I'm passing along some thoughts on the draft. I speak as a random = individual, nothing more. I'll identify the sections I am commenting on. Introduction The statement in the draft, in the abstract and in the introduction, is = that certain types of devices (and, I would argue, more accurately = applications) are only appropriately reachable from localized locations, = and therefore only using ULA addresses. This troubles me on a couple of = counts. I would agree that there are a number of classes of Internet = devices and applications that should be reachable only by their = operators. But I question whether they are necessarily in their = operators' local domains (how about outsourced datacenter etc?), or = whether their operators might have operating contracts with others that = muddy those waters? In general - and I have said this multiple times - = if a device is intended to be reachable only by systems within its local = domain, a local address (one not advertised in BGP) make sense. That = said, I seriously dispute that this is a result of the nature of the = device or its application; it is a policy decision on the part of those = who operate it. I don't think I could pass on the draft with this = confusion between nature and policy in it. For the record, I would add that folks in v6ops have commented in the = past that using ULA and GUA prefixes within an enterprise network = entails the possibility of doubling the address announcement volume - if = a given LAN has two subnets and therefore two prefixes, it would have = that result. I would therefore expect that networks using this model = would be likely to have some LANs with a GUA subnet and some LANs with a = ULA subnet, but few if any with both. There is in my view a minor = increase in complexity with this model - LANs have, if you will, an = additional attribute, which is whether its subnets are local-only or = global in nature.=20 Default Local Only Addresses Point of definition: a ULA addresses is global in scope, but may not be = advertised globally. They may, if appropriate and agreed between ASNs, = be advertised between "consenting adults". There is actually a = reasonably common use case, discussed in = draft-baker-v6ops-b2b-private-routing. I would prefer that the draft = accurately describe a ULA if it wants to talk about them. Permitted Incoming and Outgoing Connections In excluding GUA-source sessions, I think this creates unnecessary = complexity. First, if a device is using a GUA, one of two situations = exists: it is within the network and managed to select the wrong source = address, or it is outside the network, has no routing advertisement with = which to read the ULA prefix, and can't get there. Anything else (such = as the network erroneously advertised the ULA prefix and the neighboring = network failed to filter it out) is an error. My Real Concern: If I were to read this as an enterprise network operator, I think my = first reaction would be to say "I recognize this; a ULA is a private = address, and if I choose to I can translate it at the network edge". As = such, if we proceed with this, it needs to be with large health warnings = about not using translation (cf RFC 2993).= From nobody Thu Dec 5 16:00:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654671201A3; Thu, 5 Dec 2019 16:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jauurGBfIvYe; Thu, 5 Dec 2019 16:00:51 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75FD120046; Thu, 5 Dec 2019 16:00:50 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id x1so4935023qkl.12; Thu, 05 Dec 2019 16:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cOyr712R/vpYr0JFzMsbC8l5478ZfxLg/FxId1p827Q=; b=ElU+0W/RVE7tzsq7hpsFZohWfnB/xHnortCbVasrx0iyq2JSi2e2dNA3NwRUQH0/te 8L2UQqEX/9p+hE9HMHn5cEcNe7eKIDtE3g9p7/pSFesWc+aoaelGlQOIDPhq/+cIZnpG Kx2CQe+Zqvjh3vh8BQogMGnpuESfrNaQTmC1uK/0vj8Q8tr5qN+2YWloVi34CKPQW6gg 6VF5HhlQyF3l0AFdY6406aT07saXS2yY5IvJ9BStcjPTrKxGeewkxx7udIV+Wyk5nbfB EiFhDQiz33YgwPWbVcdYIu9MSgS39GciMxSUvxZxjYZJd5T1qhj64SI3eahe6i6OKmsA Bogg== 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=cOyr712R/vpYr0JFzMsbC8l5478ZfxLg/FxId1p827Q=; b=tnc2yWsZv+BEDGx0EVmgaphNSMr9j+RpEt9kujHPT5nkJzDfmcWO03AWEVEc24hgy5 X4pYRb7iK5drpJxWPVW6G376fN7lEnTC/tgYA1z448iHTJRqPra+rRIQWvsthlE7Hn99 m5IBvQL7AVThueq4FVA9v8fUyXBq4pA23sKhtGW2Mwuly5gg4a3cGwAIgnJ2An/Qd/+q aEA4qZPNvsRLMphN1vTOKpLVYlOENDapfph5o3uvW1a7Yi1116FHuT9eB8WJRUOCrt9o KWSW/2jJrLrv/v1DBq91lhTNV7Nik+HI9pXc47HUXY5S9AW04uaNgwSkVV2cyfSs1vtu k7Fw== X-Gm-Message-State: APjAAAUH5aVPov2gXHDM1q+Oi90Kfojz316Wd1PjuCfczMfjsP6cU8qi 01ROPR3YCIefUJUV0KWd1W/muPI++z/VjSmEplyPKdSY X-Google-Smtp-Source: APXvYqy+dj/tek0gIf0czKdETgtoRpGkdmR0K/tAMDsdPdegEZEAgn5Akc9KLCDclVtVAiNvqMnOfvVVmADgli826Sg= X-Received: by 2002:a37:4841:: with SMTP id v62mr4496223qka.444.1575590449600; Thu, 05 Dec 2019 16:00:49 -0800 (PST) MIME-Version: 1.0 References: <87o8wnf8p4.fsf@miraculix.mork.no> In-Reply-To: <87o8wnf8p4.fsf@miraculix.mork.no> From: Jen Linkova Date: Fri, 6 Dec 2019 11:00:37 +1100 Message-ID: To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= Cc: Roy Marples , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 00:00:53 -0000 On Thu, Dec 5, 2019 at 8:00 PM Bj=C3=B8rn Mork wrote: > There is a fair amount of IoT devices requiring access to one specific > CDN hosted dual-stack service, and only that. These devices will always > work in an IPv6 only environment, even without NAT64, and they know it. > > Not that these hosts ever will implement any new DHCP feature, but still.= . > > Hosts considering NAT64 optional for IPv6-only operation will probably > become more and more common as "all" (most) services get dual-stack. I > believe you are limiting the scope unnecessarily by requiring NAT64 > here. You are right indeed. Strictly speaking what the option signals is 'all destinations the host might want to connect to are reachable over IPv6 - either natively or by some transition mechanism deployed in the network'. Indeed *some* devices might not need NAT64 even now if all destinations they ever need access are IPv6-enabled. Maybe one day, when 99.999% of traffic becomes IPv6 we might not need NAT64. However practically speaking...While a device *might* be sure that it does not even need NAT64 and can operate on pure IPv6-only, I do not believe it's a realistic or practical to expect that a network operator would mark the given segment as 'IPv4-as-a-Service' w/o deploying NAT64. While writing the text I did think about corner cases 'all destinations the network provides an access to are Ipv6-enabled so NAT64 is not needed' but they are a corner cases and trying to capture them in the draft might do more harm than good... What we might do is to clarify the definition of an IPv6-only capable host and say that a host MAY be considered an IPv6-only capable if it's guaranteed somehow that all destinations the host ever is going to reach are IPv6-enabled - but I'm not really sure it's a good idea.. --=20 SY, Jen Linkova aka Furry From nobody Thu Dec 5 16:05:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4F2120046 for ; Thu, 5 Dec 2019 16:05:53 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LP25pmvKaoz for ; Thu, 5 Dec 2019 16:05:52 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F7C120033 for ; Thu, 5 Dec 2019 16:05:52 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id w47so5385118qtk.4 for ; Thu, 05 Dec 2019 16:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EjvV3YEREetLcs7D4r4sj9xPvSlXdj4nCaBILD+vwHo=; b=UjadNk+BStMbxlFNGl75bGpW5CrxkSoM4NHaZ23/a32Paen5bGylaRnXmAeBK4SiJu 6gTHiRwislRWnNXp7GhmqUDcUNQgPp8h0XKCJFn7l3Kwu7g6BtZs1bbCVbXVVPt12sBM X24hF5A956LZ8LTO26gixM8L7VfHm1gV6mjwin7Pz3HZIv4ToHCZ0/KWSWeItjwKTc7d EZ91mEZvwY8pCYTO+OX+gOWJORk6iDyQZX/eMtEyqFQZf16Cu0ikFm5A5G1AFswSwajl 4+shZai2ondi/jRRnflAgg5w5h+9BFIc/KG4BYzX+23jXlhSPzVS3AbX3PQmSr2l4WkQ L8XQ== 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=EjvV3YEREetLcs7D4r4sj9xPvSlXdj4nCaBILD+vwHo=; b=I1MMOEazwO4Igh8JPQXEdOw+Cycu921pIsY4C8BwrEn/7LsEWkX75GF5vaWjbzI9N9 eZFUkLjKfOYkzrRNt6znfs5tH8U9nopoHJl7jV8kYq1iv3E27pGrhR58Z9yl2NqafZCe xZL2t4C3Qi1dDdrp2fBUjTd9m4uSEg+LybU5XEIdl5I2b+FrL8ApgIah6EWDcNuXnVeF NpH8tfBCxENHdm68lbyFAyN3jb0VUsjvGFvasQNKdcTfDgmX6xczmON5PgoLPukq2H3m Kx0En89YaHPn6QJUan5RMfBRu8txRm7P/wFp42p0V1sBBkLHQNl9Z/ZPmklhd/w7HJH6 CHig== X-Gm-Message-State: APjAAAU3GqQVYmRrP1Pd+8H+FWZcSa04ag2Rc6UGW0riBHomWj6Nh3W7 X084hrb+qhrUktHOWwKyT1/QDdERTiMJ3aKfOxM= X-Google-Smtp-Source: APXvYqxtfLsD409xlu5WXfWsnrTO9aV2muEcZjkVahkWCYTIoW6jpVI+Q54quMT7+2Oj0i3wUGlIjWN1iRCLmlfWrzo= X-Received: by 2002:ac8:5313:: with SMTP id t19mr10391905qtn.118.1575590751259; Thu, 05 Dec 2019 16:05:51 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> <73509531-D012-49E2-8F82-D5A0659E61D4@thehobsons.co.uk> In-Reply-To: <73509531-D012-49E2-8F82-D5A0659E61D4@thehobsons.co.uk> From: Jen Linkova Date: Fri, 6 Dec 2019 11:05:39 +1100 Message-ID: To: Simon Hobson Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 00:05:54 -0000 On Fri, Dec 6, 2019 at 3:17 AM Simon Hobson wrote: > > Another typo, I think. Top of page 2 it says : > "Therefore it would be beneficial for IPv6 deployment if operators could implement IPv4-mostly (or IPv4-as-a-Service) segments ..." > Should that be IPv6-mostly ? Oh indeed, thanks for pointing this out. I seem to constantly mistake IPv4 for IPv6 and vice versa in the draft ;)) Will fix in -01. -- SY, Jen Linkova aka Furry From nobody Thu Dec 5 16:41:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9241201A3 for ; Thu, 5 Dec 2019 16:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 i8Tp5ihkMgf5 for ; Thu, 5 Dec 2019 16:41:43 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCAF1200C4 for ; Thu, 5 Dec 2019 16:41:43 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id z90so4707883ilc.8 for ; Thu, 05 Dec 2019 16:41:43 -0800 (PST) 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=jvTIOWlFk9XmmDnrBPOZteACEkwkMfaOW/ZRf3v0Kw8=; b=Xwn0Ru+DErAA018ovA017aNa2cPaAmoqi+qR7/HUVXERgtP6ilIjZUhfcXYZIE4ciU q2SOzEEOZ0Ln8ouJ9TGGBDkHch6g4Z8ssrlVR87msyzu+4CYZQalr4+POpblkdzF1VHn sJgGTIPDJsCb0bg92J8A1PqK8OB7Tvhoc4g2kndp2Mr2B0NFXfkgjlEzoVbpexOQIihd /oaZgu1NEnQ1GOnAgoZHXa0SFBtsE6bSnPvcqfkET1osz5LOfyr/AacUN76TmqQoBnHP 4BCBkrqL+/SOfazrEFaC5NDpJFAFpM5nW31CGGRFd2gUgioKCfZzOS3dEY4nVtYS0Ntj JWDA== 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=jvTIOWlFk9XmmDnrBPOZteACEkwkMfaOW/ZRf3v0Kw8=; b=evydxbaQzz1Qlz2p/OEH8WQ8WUzBF8vTaoo+7TbY8+VrXav7ib+JjN1sHLkUFyJm18 ryNrfepGoS1j2fjx2hgsaIpSgiovbl8gwKahinqY3HJqxQZTdSvbxpCElY2ISdLO2Aqs +NBJoneLLRNKsakn/MuVc3naMi6LqC5tHHMwT/yy0GnCu5aFIbOK46QFxN3tb37W6N6i u9HkoB6t/pC4XBVNuT0GdKIzAxX3lwjZ7F1/uccMvr232ZCKHoUaH/fVk2KazX3rWOxk YmSehlKSpkHbCygtk97sTHrsd9WJLZqgw4PBgDdENBOZ0kxTUwNqQ+aaOsGM8FdheuyT qMtg== X-Gm-Message-State: APjAAAUznuGGM1Y4IsdQSH0vjcMv7n+8GtBkXVFdaEIcsAbOruTD14vK 8hRuij5tJgIpxbaMlkQubz3/grGmrt1BtbtIUfvjjw== X-Google-Smtp-Source: APXvYqwi1Ue5ehDibROna6ISIV0W9eTzFH4bJNsMOiF3lvIlBlqkRVLIcYQZjJjOao9zzwWAnTSrDL5e+7d4Hi43xtQ= X-Received: by 2002:a92:3b10:: with SMTP id i16mr12483227ila.170.1575592902668; Thu, 05 Dec 2019 16:41:42 -0800 (PST) MIME-Version: 1.0 References: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com> In-Reply-To: From: Lorenzo Colitti Date: Fri, 6 Dec 2019 09:41:29 +0900 Message-ID: To: Roy Marples Cc: Ted Lemon , Tomek Mrugalski , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: multipart/alternative; boundary="00000000000046ad550598fe4f23" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 00:41:45 -0000 --00000000000046ad550598fe4f23 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 5, 2019 at 11:48 PM Roy Marples wrote: > The *something* else is probably IPv6 but I don't see why this RFC > should mention it other than a use case. > There is actually a reason why the option is specific to IPv6. Here's why. The primary reason for the existence of option is that hosts (especially moblie hosts) don't want to wait to find out what's available before they make networking available to applications. This is why when they connect they initiate IPv4 and IPv6 (and whatever else they have) in parallel. The option as written conveys two important bits of information to the host: 1. The network would prefer the host not use IPv4 if the host has something else available. 2. Something else *is available* on this network, so the host is not going to wait forever for it. In the current draft, "something else" is specifically IPv6 (because not really any other credible alternative to IPv4) and more specifically, IPv6 with NAT64 (because there is no other IPv6 transition mechanism that is widely implemented in hosts today - all the others are implemented in the network). I think you're saying that this option should mean "I'd prefer you not use IPv4 except as a last resort" option, as opposed to "I'd prefer you use IPv6 instead". What that means is that the option will only be providing #1 and not #2. I think it's worse that what we are currently proposing. The reasons are: 1. If we make this an "IPv4 as last resort" option, a client that gets the option is not being told if there is anything else available. So, say that the administrator sets this option because they want hosts to prefer IPX (or netbeui, or appletalk, or whatever) over IPv4. What if the host doesn't support/use any of those protocols, but only supports IPv6, which is the overwhelmingly common case today? The host doesn't really have a clear path forward. The only thing it can do is try IPv6 "for a while", and then go back to DHCPREQUEST (assuming the offer is still valid, and if not go back to DHCPDISCOVER), and use IPv4 anyway. That seems like a bad user experience. 2. If we make this an "IPv4 as a last resort option" instead of a "please use IPv6" option, is that hosts will simply assume that the option means "please use IPv6". Even though this assumption is technically incorrect, if enough hosts do it, from a deployment perspective it won't matter, because network operators won't be able to use this option code for anything other than IPv6-only networks. That outcome is worse than if we had explicitly defined this as a "please use IPv6" option, because well-behaved hosts will have to incur the additional complexity to build the technically correct implementation that can never be used in practice. If we really don't want to make this option specific to IPv6, then we can define an option that can convey multiple alternatives. In other words, the option would mean "please don't use IPv4 if you support any of the alternative protocols listed in this option". We could initially define an alternative code only for "IPv6-only with NAT64", but if later some other protocol comes along, or some other IPv6 transition mechanism becomes widely deployed on hosts, we could add a code for it. Personally I don't think this is worth the engineering complexity because I don't see any other credible alternative than IPv6-only with NAT64, but I would much prefer it over an option that doesn't say anything at all about what else is available. --00000000000046ad550598fe4f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 5, 2019 at 11:48 PM Roy Marpl= es <roy@marples.name> wrote:<= br>
The *something* else is probably IPv6 but I don't see why th= is RFC
should mention it other than a use case.

There is actually a reason why the option is specific to IPv6. Here's= why. The primary reason for the existence of option is that hosts (especia= lly moblie hosts) don't want to wait to find out what's available b= efore they make networking available to applications. This is why when they= connect they initiate IPv4 and IPv6 (and whatever else they have) in paral= lel. The option as written conveys two important bits of information to the= host:
  1. The network would prefer the host not use IPv4 if = the host has something else available.
  2. Something else *is available= * on this network, so the host is not going to wait forever for it.
    3. In the current draft, "something else" is specifically IPv= 6 (because not really any other credible alternative to IPv4) and more spec= ifically, IPv6 with NAT64 (because there is no other IPv6 transition mechan= ism that is widely implemented in hosts today - all the others are implemen= ted in the network).

I think you're sayi= ng that this option should mean "I'd prefer you not use IPv4 excep= t as a last resort" option, as opposed to "I'd prefer you use= IPv6 instead". What that means is that the option will only be provid= ing #1 and=C2=A0not #2. I think it's worse that what we are currently p= roposing. The reasons are:
  1. If we make this an "IPv4 = as last resort" option, a client that gets the option is not being tol= d if there is anything else available. So, say that the administrator sets = this option because they want hosts to prefer IPX (or netbeui, or appletalk= , or whatever) over IPv4. What if the host doesn't support/use any of t= hose protocols, but only supports IPv6, which is the overwhelmingly common = case today? The host doesn't really have a clear path forward. The only= thing it can do is try IPv6 "for a while", and then go back to D= HCPREQUEST (assuming the offer is still valid, and if not go back to DHCPDI= SCOVER), and use IPv4 anyway. That seems like a bad user experience.
    2. If we make this an "IPv4 as a last resort option" instead of a = "please use IPv6" option, is that hosts will simply assume that t= he option means "please use IPv6". Even though this assumption is= technically incorrect, if enough hosts do it, from a deployment perspectiv= e it won't matter, because network operators won't be able to use t= his option code for anything other than IPv6-only networks. That outcome is= worse than if we had explicitly defined this as a "please use IPv6&qu= ot; option, because well-behaved hosts will have to incur the additional co= mplexity to build the technically correct implementation that can never be = used in practice.
If we really don't want to make t= his option specific to IPv6, then we can define=C2=A0an option that can con= vey multiple alternatives. In other words, the option would mean "plea= se don't use IPv4 if you support any of the alternative protocols liste= d in this option". We could initially define an alternative code only = for "IPv6-only with NAT64", but if later some other protocol come= s along, or some other IPv6 transition mechanism becomes widely deployed on= hosts, we could add=C2=A0a code for it. Personally I don't think this = is worth the engineering complexity because I don't see any other credi= ble alternative than IPv6-only with NAT64, but I would much prefer it over = an option that doesn't say anything at all about what else is available= .
--00000000000046ad550598fe4f23-- From nobody Thu Dec 5 16:59:06 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960D0120220 for ; Thu, 5 Dec 2019 16:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPTH-BoJuR52 for ; Thu, 5 Dec 2019 16:59:04 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::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 0F24D12021C for ; Thu, 5 Dec 2019 16:59:04 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id b8so4636495oiy.5 for ; Thu, 05 Dec 2019 16:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VpKldaa18sFKS6rM1CfvtxxD83q7wVofplMnr7Xt5H8=; b=gcTpbIpCJX32v4+Hq58muueJSOp7vwhsaBrM89wjBPR12Qg6PaRN4WHcAC80c360oC YTvkqyX7AxoFNQE69ESZztaXoCJnoDLgoJ3Q4iMJwDJMprzl5LOzIucFXqQnqLOsv6pW mcPduNm2bTZWhK1D8HNXE7t61XxxpmjrVRO2ts23o1i71u74b13qjNnjCJ3rbxMmPA2X q/ClAofh/DfMq3f7D6diWUzsHXa061gRBspY3Uf/VRJKWQ9w2TyP9Yf2TaE20DtchzJm +A1pCOj36rFKzCWhavzPuqQ/xIaayPCUbk0glmov+XIqcwDfb49pOaUtIoeCVvBFKeY/ cXmg== 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=VpKldaa18sFKS6rM1CfvtxxD83q7wVofplMnr7Xt5H8=; b=ku92mRK3GblKx5P1mhQHCZKTtQQtbiNteOGUbVRlOKzarRqD3jgNjJYNHEBkRn4lZR VDYHoqHdzJuPe2wSr0aih8tkOKaP7ogZvn4zMlPLCEJaae8bUwE7qB9PJ71+cF0AspEY S0WCnPkyKr2GNeTMKXX9JeAdsa3uQMGldmTA1AOkvxSm/XWoebfpjhERPZip6LSIWCcv ycwaIEsKKeLOUp1yust7VtZcdgdcUY8gqHFHiwKpBLObJxlNYaS1yUaPdWQwVXvBR0O2 2VI7yFchu4T5vKs+Bx+5L2+GmrOB8r+kT6Ue2LmpHNA0x7EOFpNGz3y0WxcVsykifvWT ZvVA== X-Gm-Message-State: APjAAAVk5bbYTLPLlp2aCeQde8TLfs/45cyyBALqKsAcPn5U/7p64Gju YF2LoPofMCf4p7HSYudEtmIGF4Vy4RZ+z/1QtWM= X-Google-Smtp-Source: APXvYqzr+PzrvpPClBYlezNlWJa1JgLpjyGCSM6fo+9uSb3AoyvsQ0A3JnZFEI61a4SEAwtt+4Y/VV7INQEDkeQWvxw= X-Received: by 2002:a05:6808:f:: with SMTP id u15mr9797532oic.164.1575593943238; Thu, 05 Dec 2019 16:59:03 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <9bd73ee1-46f7-5084-06a6-59c7b391f9cb@foobar.org> In-Reply-To: From: Mark Smith Date: Fri, 6 Dec 2019 11:58:36 +1100 Message-ID: To: Lorenzo Colitti Cc: Lorenzo Colitti , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 00:59:06 -0000 On Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti wrote: > > On Thu, Dec 5, 2019 at 9:53 AM Mark Smith wrote: >> >> If hosts only acquired IPv4 addresses via DHCPv4 based on when the first= IPv4 application started running, then when a host is only running IPv6 on= ly applications, it would never acquire an IPv4 address because it wouldn't= need one, meaning never try to use DHCPv4 (so would avoid the link-layer b= roadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP = Requests). > > > Speaking as an OS implementer: how do I know whether an application is an= IPv4 application? > So these are reasonable questions, and they're uncovering some assumptions and a view point I have: - the hosts in question are commonly single homed (and I should know better *, however I would't be surprised if that is the unstated assumption of most people when they imagine the scenario being discussed) - the on-demand I'm imagining is inspired by the dial-on-demand that used to be implemented with ISDN, triggered by IP traffic. ISDN connection establishment happened quickly enough that it was tolerable by end-users. If a DHCPv4 transaction occurred within 100 ms, users will perceive it as instant - "Response Times: The 3 Important Limits" - https://www.nngroup.com/articles/response-times-3-important-limits/ - IPv6 only applications clearly indicate they're IPv6 only, by only opening IPv6 sockets. This latter point is probably a significant difference between what is being proposed here and what I'm thinking. My thinking is probably about a passive and longer term mechanism that would result in IPv4 disappearing over time, rather than an active mechanism that purposely switches IPv4 off on dual stack hosts. Responding to these points for completeness: > When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do that. They wouldn't be IPv6 Only applications. > When it creates an IPv4 socket? But what if it's creating an IPv4 socket = for the purpose of connecting to another network on the system (e.g., cellu= lar data) that does have IPv4? Yes, this would be an issue with what I was describing. What I'm thinking about would probably more result in "IPv6 Only" being a host level status on a host, covering all interfaces (1 or many), rather than an interface status. In other words, if a host is only currently running IPv6 Only applications, then there is no need for any IPv4 addresses on any of its interfaces. > When it does a connect() on an IPv4 socket? But what if that's just a hap= py eyeballs stack that is using IPv4 because it might be available? As above, not an IPv6 Only application if trying to use HE. > What if the app knows it needs IPv4 and will refuse to do any networking = if it doesn't find an IPv4 address on the system? Not an IPv6 Only application. I see value in both applications being explicit about what Internet Protocol they want to use (e.g. on demand addressing per above), and also being agnostic about it. Regards, Mark. (* "The Rapid Rise of the Mobile Multi-Homed Host" - https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20= P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf) From nobody Thu Dec 5 17:50:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C4B12004C for ; Thu, 5 Dec 2019 17:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bet_0QyQz9Qc for ; Thu, 5 Dec 2019 17:50:09 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80838120018 for ; Thu, 5 Dec 2019 17:50:09 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id n13so2505380pff.1 for ; Thu, 05 Dec 2019 17:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=82eBUpoOTCiRPWxVkv5OWXGwxCqyVzRxJTmrD7Z+XuA=; b=inhW/VA7HF4xusoTiivpu5jlO1IVea4pIRv3g1JGTfHvvPN3aLpn4hczu/8TA4ds/F dmcuvyR6Ay7Cl6hBXuD9XMMGIj7QqxVOc5kDCEISpAWh5memlX8xvq9ga5488EkmWZfY gs8rHBHhY14tgWByMj164zSaYkiyBFLk9Yi+OpbNqMB72hQY/kXogGnzUqMO0pVJGIBN Zx+x927fKS50a7fJwLEGM6mAG78xsuQ7zV/PuEmLcWjtIV7ikjmAEh8VxvJQPVdvtPlY Pdvv7Whr+5R0a/Xs6nGS62rb2O5oYsydiDgnEse0d5Bgq1uk5ufJOjiiI9XDyI/dQ2E2 BWUA== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=82eBUpoOTCiRPWxVkv5OWXGwxCqyVzRxJTmrD7Z+XuA=; b=Q1Kd7LQrcLiCr0zVPlcQ6myYg5GwTvnu5VvuFa1ZuEuSwmf10GJxxceU/Tfzw+XTGZ h+p3z6s0WGFdSL45fOnlrK7rkCG0QkvUlqZxjiqlfT4HAAWnGSkoT9o7kWPITzmwxGCS 6CHoHaXllc9a2Z7Tsin8z70nE60x17yEv8r+H3pHwFJ0vYDSLc8KUvEjg1jlm26sXr+c kCG2bE83rimc5aHq70K6enDZ5eGxSodhHuTPKt4h+RL/t+9slroU00Xf/CRTyGwuUZeA Vzgq9rv7OYMhucgdXUWX3fbSaQunGHrEUDWgAcWheHWUeVmjYzYtpkR+QL1zG7/C3Gz6 rpog== X-Gm-Message-State: APjAAAVpk9x1s4Nxr6+lO5s2p6GL5q41ht8on5P7pJtO9oZqF7iZtSEm L4lrC0nsPATsn/z46EtZHFc9pQ== X-Google-Smtp-Source: APXvYqxTmjX5NiC2nzJ3E8o8Zvh94Yx+ujwUt/gyaYeYae1LjAIMh4Et7Z6Uza4ukHGJMbsYrHNGvw== X-Received: by 2002:a63:6b8a:: with SMTP id g132mr757582pgc.127.1575597008898; Thu, 05 Dec 2019 17:50:08 -0800 (PST) Received: from ?IPv6:2600:380:852e:6ef7:4dd6:1fa6:7c9b:1aca? ([2600:380:852e:6ef7:4dd6:1fa6:7c9b:1aca]) by smtp.gmail.com with ESMTPSA id u65sm13719768pfb.35.2019.12.05.17.50.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2019 17:50:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 5 Dec 2019 17:50:06 -0800 Message-Id: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com> References: Cc: Lorenzo Colitti , v6ops list , Lorenzo Colitti In-Reply-To: To: Mark Smith X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 01:50:13 -0000 What=E2=80=99s an ipv6-only application? Normally I would expect an applica= tion to be stack-neutral.=20 > On Dec 5, 2019, at 16:59, Mark Smith wrote: >=20 > =EF=BB=BFOn Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti = wrote: >>=20 >>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith wrote= : >>>=20 >>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the first= IPv4 application started running, then when a host is only running IPv6 onl= y applications, it would never acquire an IPv4 address because it wouldn't n= eed one, meaning never try to use DHCPv4 (so would avoid the link-layer broa= dcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requ= ests). >>=20 >>=20 >> Speaking as an OS implementer: how do I know whether an application is an= IPv4 application? >>=20 >=20 > So these are reasonable questions, and they're uncovering some > assumptions and a view point I have: >=20 > - the hosts in question are commonly single homed (and I should know > better *, however I would't be surprised if that is the unstated > assumption of most people when they imagine the scenario being > discussed) >=20 > - the on-demand I'm imagining is inspired by the dial-on-demand that > used to be implemented with ISDN, triggered by IP traffic. ISDN > connection establishment happened quickly enough that it was tolerable > by end-users. If a DHCPv4 transaction occurred within 100 ms, users > will perceive it as instant - "Response Times: The 3 Important Limits" > - https://www.nngroup.com/articles/response-times-3-important-limits/ >=20 > - IPv6 only applications clearly indicate they're IPv6 only, by only > opening IPv6 sockets. >=20 > This latter point is probably a significant difference between what is > being proposed here and what I'm thinking. My thinking is probably > about a passive and longer term mechanism that would result in IPv4 > disappearing over time, rather than an active mechanism that purposely > switches IPv4 off on dual stack hosts. >=20 >=20 > Responding to these points for completeness: >=20 >> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do that.= >=20 > They wouldn't be IPv6 Only applications. >=20 >=20 >> When it creates an IPv4 socket? But what if it's creating an IPv4 socket f= or the purpose of connecting to another network on the system (e.g., cellula= r data) that does have IPv4? >=20 > Yes, this would be an issue with what I was describing. >=20 > What I'm thinking about would probably more result in "IPv6 Only" > being a host level status on a host, covering all interfaces (1 or > many), rather than an interface status. In other words, if a host is > only currently running IPv6 Only applications, then there is no need > for any IPv4 addresses on any of its interfaces. >=20 >=20 >> When it does a connect() on an IPv4 socket? But what if that's just a hap= py eyeballs stack that is using IPv4 because it might be available? >=20 > As above, not an IPv6 Only application if trying to use HE. >=20 >=20 >> What if the app knows it needs IPv4 and will refuse to do any networking i= f it doesn't find an IPv4 address on the system? >=20 > Not an IPv6 Only application. >=20 >=20 > I see value in both applications being explicit about what Internet > Protocol they want to use (e.g. on demand addressing per above), and > also being agnostic about it. >=20 >=20 >=20 > Regards, > Mark. >=20 >=20 >=20 > (* "The Rapid Rise of the Mobile Multi-Homed Host" - > https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%2= 0P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf) >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 5 17:58:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93C120072 for ; Thu, 5 Dec 2019 17:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_8-IB8x8-s6 for ; Thu, 5 Dec 2019 17:58:15 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BF8120018 for ; Thu, 5 Dec 2019 17:58:15 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id p8so4466844oth.10 for ; Thu, 05 Dec 2019 17:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tW0HJss4AIRf0dVmMMfu/bIHTRUVWOQ+PYRZtxunC88=; b=TEC2H8denBW7BYD55FBVdZPiZQT2ImPl8E7hxRwZZr4jwarjMrZaLpvk5TDBuVUYqQ B9NfKfZmMHhfMEAdCArcJf+2QYeEagmILXJAIZ1rfJXhxTwX3mFRWllwd6jzIITdtGI6 QTFlmmhm4x+oggaPWJXAePtVI1+aTT15qnwUv/eMhWWqE3irvm9mUzd8/koRRZm72KTY MUyfuH5HPM9SKo4VCiWyzI6pFQAm7r9h2sMZwgCcGSpSWpwypapxPQlOh7jkRKgyvUBf trYhNGvN1hoqo9raavH34vj9iFUbPX1p2ttP73GMGOqmUylZW+LqcHpAr+ycF9nCxm1G JuKw== 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=tW0HJss4AIRf0dVmMMfu/bIHTRUVWOQ+PYRZtxunC88=; b=ASLEFF7PDYePS/5g0YZIownR3VNb/P5nzCAcdtcawab2nQYwhDqvM1Zqz5aaUXzvSA 8moVOdTvVTJd2/YQbzntB/EgBAmlmUQ+hHeVf9/Cll3Oj+QweaOhH3sNAUTnlUheBmTw Ff7HM8USxYBykiKK6nuEhLRGD3Vr+SB9bRupkO+FyD5z1V5i0ZSBeU53Vt6huIjNw8k6 pnUO13chRaI6oapgBvJmep4Qhz9h4XphTmktN2aXVeMLlXqf3gYCeInJ3rT3eT6oNg7Y 1nEaIrJjrQ0/nSz4S5r/eXZnHKj1gtAzjL/Ly4YshZpSYCmwGD0NPlkGM3hFbVx6CtN7 qytg== X-Gm-Message-State: APjAAAVF80wr96Z6XAUHbBCE9V42syyKwaSphg5kTO54R3srZovSfdf8 d1+OTcT3GkagpLVTkonPSTJbLKJoQGk5X+SfIUw= X-Google-Smtp-Source: APXvYqyLnsw/ZKbGcFeFP3i3y6ynjvo29jwP91teLGgP9jlnh5QTWGf8dyJnpRKlk85s+KN/bKfwG44tbKdZedhXK54= X-Received: by 2002:a9d:6005:: with SMTP id h5mr9832319otj.153.1575597495053; Thu, 05 Dec 2019 17:58:15 -0800 (PST) MIME-Version: 1.0 References: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com> In-Reply-To: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com> From: Mark Smith Date: Fri, 6 Dec 2019 12:57:48 +1100 Message-ID: To: Ted Lemon Cc: Lorenzo Colitti , v6ops list , Lorenzo Colitti Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 01:58:17 -0000 On Fri, 6 Dec 2019 at 12:50, Ted Lemon wrote: > > What=E2=80=99s an ipv6-only application? Normally I would expect an appl= ication to be stack-neutral. > >From RFC 3493: For example, to create an IPv6/TCP socket, applications make the call: s =3D socket(AF_INET6, SOCK_STREAM, 0); To create an IPv6/UDP socket, applications make the call: s =3D socket(AF_INET6, SOCK_DGRAM, 0); For example, this application only listens on IPv4 or IPv6, but never both: https://github.com/markzzzsmith/replicast Regards, Mark. > > On Dec 5, 2019, at 16:59, Mark Smith wrote: > > > > =EF=BB=BFOn Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti wrote: > >> > >>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith wr= ote: > >>> > >>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the fi= rst IPv4 application started running, then when a host is only running IPv6= only applications, it would never acquire an IPv4 address because it would= n't need one, meaning never try to use DHCPv4 (so would avoid the link-laye= r broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast A= RP Requests). > >> > >> > >> Speaking as an OS implementer: how do I know whether an application is= an IPv4 application? > >> > > > > So these are reasonable questions, and they're uncovering some > > assumptions and a view point I have: > > > > - the hosts in question are commonly single homed (and I should know > > better *, however I would't be surprised if that is the unstated > > assumption of most people when they imagine the scenario being > > discussed) > > > > - the on-demand I'm imagining is inspired by the dial-on-demand that > > used to be implemented with ISDN, triggered by IP traffic. ISDN > > connection establishment happened quickly enough that it was tolerable > > by end-users. If a DHCPv4 transaction occurred within 100 ms, users > > will perceive it as instant - "Response Times: The 3 Important Limits" > > - https://www.nngroup.com/articles/response-times-3-important-limits/ > > > > - IPv6 only applications clearly indicate they're IPv6 only, by only > > opening IPv6 sockets. > > > > This latter point is probably a significant difference between what is > > being proposed here and what I'm thinking. My thinking is probably > > about a passive and longer term mechanism that would result in IPv4 > > disappearing over time, rather than an active mechanism that purposely > > switches IPv4 off on dual stack hosts. > > > > > > Responding to these points for completeness: > > > >> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do th= at. > > > > They wouldn't be IPv6 Only applications. > > > > > >> When it creates an IPv4 socket? But what if it's creating an IPv4 sock= et for the purpose of connecting to another network on the system (e.g., ce= llular data) that does have IPv4? > > > > Yes, this would be an issue with what I was describing. > > > > What I'm thinking about would probably more result in "IPv6 Only" > > being a host level status on a host, covering all interfaces (1 or > > many), rather than an interface status. In other words, if a host is > > only currently running IPv6 Only applications, then there is no need > > for any IPv4 addresses on any of its interfaces. > > > > > >> When it does a connect() on an IPv4 socket? But what if that's just a = happy eyeballs stack that is using IPv4 because it might be available? > > > > As above, not an IPv6 Only application if trying to use HE. > > > > > >> What if the app knows it needs IPv4 and will refuse to do any networki= ng if it doesn't find an IPv4 address on the system? > > > > Not an IPv6 Only application. > > > > > > I see value in both applications being explicit about what Internet > > Protocol they want to use (e.g. on demand addressing per above), and > > also being agnostic about it. > > > > > > > > Regards, > > Mark. > > > > > > > > (* "The Rapid Rise of the Mobile Multi-Homed Host" - > > https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D0= 1%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf) > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 5 18:37:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB5120072 for ; Thu, 5 Dec 2019 18:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa6n-dLJHQbC for ; Thu, 5 Dec 2019 18:37:36 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B4F12004C for ; Thu, 5 Dec 2019 18:37:36 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id x8so2513341pgk.8 for ; Thu, 05 Dec 2019 18:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=+MRfAguxVXMOjp9EqCUSZpJydcWiliRa6jUl2JlPpr8=; b=w2KCLINVf9vwy3DSdngN1Wt5bs1UwX1JUpaoDYve4RSuqGDSyTeMks0/a4PUXDerfh yNY5VuDCzzyf0e+G2gWUybbLQQjiS27UM0UI8HUHLhj98nJd/Nz9K6tIoSnxyx6ldPmz HiIKvIYUoLitCnp2gfg4NbG2isRhjTbhma9wmDPdNp7GYADisMohOq0iGn55Q8DHNOFC MQIyy6LcwF3flc5NScrfp5aJYz7WLWfRcY70Q3GnTrNvYs/AEVfzFfwI2F/U1mTItz7Y eHcA3vyBUP1gijjBxZXmIzWkhS1OcnGCSsMFRKTXrJDuHJ2JPZ8gIJTI59ToPGscKM5f eofg== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=+MRfAguxVXMOjp9EqCUSZpJydcWiliRa6jUl2JlPpr8=; b=n1uQY8b9/z3gQ9FQm+lH+20CsFowe/FRq5hDufZfIB12cXwVYBtNMdsVtHwtL/ZMeS gXy6iq8hD3u0/4PUUemsZfmU9DDnIitOhl3UkM43uuaRXKWgoYTi7pUB+xGS0+5sDvzU qG66lIpgJUz+Fu62VkoTrFTAJsvFIeRSzxw7ZVej/554s7VqW1h/luDOthliIAsdiYv8 i6PrCJZhT048ZOBp88GX2uwX/d3P/MYELIzSF2THOevJVirfUNBGUwDOhnnD0dxAhgbD ixUhL/gluTTYbncUfYZZMIWHYTCKMoCmooa+hEib80EMB/8LlhXxcOIEEa/QvSTTdmyc Z3Fg== X-Gm-Message-State: APjAAAXV7inl8rRMIvjWZ1oYthKI9rnrKvd+6e6aL9htJfZX9Ve5qUgh zD6jHbzLM3hKYhuo9Mhaou1voQ== X-Google-Smtp-Source: APXvYqyZcv3Syv966XR0Gj3ttaLrETiBXiiMo4tckWSZ1krjIZwgLkH6kB9AnMIjtVM9y4sDGG0UHg== X-Received: by 2002:a63:6a09:: with SMTP id f9mr928030pgc.425.1575599856012; Thu, 05 Dec 2019 18:37:36 -0800 (PST) Received: from [10.20.3.126] (ip-64-134-236-149.public.wayport.net. [64.134.236.149]) by smtp.gmail.com with ESMTPSA id 17sm14201218pfv.142.2019.12.05.18.37.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2019 18:37:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 5 Dec 2019 18:37:33 -0800 Message-Id: <6C2B751E-9402-4ABD-830B-C9099AA97994@fugue.com> References: Cc: Lorenzo Colitti , v6ops list , Lorenzo Colitti In-Reply-To: To: Mark Smith X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 02:37:43 -0000 That wasn=E2=80=99t my question. I know how to write one. Can you give me an= example of one in the wild? It has to be something that gets serious use.=20= > On Dec 5, 2019, at 17:58, Mark Smith wrote: >=20 > =EF=BB=BFOn Fri, 6 Dec 2019 at 12:50, Ted Lemon wrote: >>=20 >> What=E2=80=99s an ipv6-only application? Normally I would expect an appl= ication to be stack-neutral. >>=20 >=20 > =46rom RFC 3493: >=20 > For example, to create an IPv6/TCP socket, applications make the > call: >=20 > s =3D socket(AF_INET6, SOCK_STREAM, 0); >=20 > To create an IPv6/UDP socket, applications make the call: >=20 > s =3D socket(AF_INET6, SOCK_DGRAM, 0); >=20 >=20 > For example, this application only listens on IPv4 or IPv6, but never both= : >=20 > https://github.com/markzzzsmith/replicast >=20 >=20 > Regards, > Mark. >=20 >=20 >>>> On Dec 5, 2019, at 16:59, Mark Smith wrote: >>>=20 >>> =EF=BB=BFOn Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti wrote: >>>>=20 >>>>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith wro= te: >>>>>=20 >>>>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the fir= st IPv4 application started running, then when a host is only running IPv6 o= nly applications, it would never acquire an IPv4 address because it wouldn't= need one, meaning never try to use DHCPv4 (so would avoid the link-layer br= oadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Re= quests). >>>>=20 >>>>=20 >>>> Speaking as an OS implementer: how do I know whether an application is a= n IPv4 application? >>>>=20 >>>=20 >>> So these are reasonable questions, and they're uncovering some >>> assumptions and a view point I have: >>>=20 >>> - the hosts in question are commonly single homed (and I should know >>> better *, however I would't be surprised if that is the unstated >>> assumption of most people when they imagine the scenario being >>> discussed) >>>=20 >>> - the on-demand I'm imagining is inspired by the dial-on-demand that >>> used to be implemented with ISDN, triggered by IP traffic. ISDN >>> connection establishment happened quickly enough that it was tolerable >>> by end-users. If a DHCPv4 transaction occurred within 100 ms, users >>> will perceive it as instant - "Response Times: The 3 Important Limits" >>> - https://www.nngroup.com/articles/response-times-3-important-limits/ >>>=20 >>> - IPv6 only applications clearly indicate they're IPv6 only, by only >>> opening IPv6 sockets. >>>=20 >>> This latter point is probably a significant difference between what is >>> being proposed here and what I'm thinking. My thinking is probably >>> about a passive and longer term mechanism that would result in IPv4 >>> disappearing over time, rather than an active mechanism that purposely >>> switches IPv4 off on dual stack hosts. >>>=20 >>>=20 >>> Responding to these points for completeness: >>>=20 >>>> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do tha= t. >>>=20 >>> They wouldn't be IPv6 Only applications. >>>=20 >>>=20 >>>> When it creates an IPv4 socket? But what if it's creating an IPv4 socke= t for the purpose of connecting to another network on the system (e.g., cell= ular data) that does have IPv4? >>>=20 >>> Yes, this would be an issue with what I was describing. >>>=20 >>> What I'm thinking about would probably more result in "IPv6 Only" >>> being a host level status on a host, covering all interfaces (1 or >>> many), rather than an interface status. In other words, if a host is >>> only currently running IPv6 Only applications, then there is no need >>> for any IPv4 addresses on any of its interfaces. >>>=20 >>>=20 >>>> When it does a connect() on an IPv4 socket? But what if that's just a h= appy eyeballs stack that is using IPv4 because it might be available? >>>=20 >>> As above, not an IPv6 Only application if trying to use HE. >>>=20 >>>=20 >>>> What if the app knows it needs IPv4 and will refuse to do any networkin= g if it doesn't find an IPv4 address on the system? >>>=20 >>> Not an IPv6 Only application. >>>=20 >>>=20 >>> I see value in both applications being explicit about what Internet >>> Protocol they want to use (e.g. on demand addressing per above), and >>> also being agnostic about it. >>>=20 >>>=20 >>>=20 >>> Regards, >>> Mark. >>>=20 >>>=20 >>>=20 >>> (* "The Rapid Rise of the Mobile Multi-Homed Host" - >>> https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01= %20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf) >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 5 19:25:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429712006F for ; Thu, 5 Dec 2019 19:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqgrMQOmr4WD for ; Thu, 5 Dec 2019 19:24:59 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 AF0F412000F for ; Thu, 5 Dec 2019 19:24:59 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id 6so4890187oix.7 for ; Thu, 05 Dec 2019 19:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JQQNbW8cStAx6+ohPWfDmzYVgImJEYYic+pZzsxiTxQ=; b=YI39c5yH+1FzBHAvgRUHyPKDjzx4RxPrXcWW4X3XyRpOIhUBlBrFFhdTq3k+PXp0Yg p2rLYDj7T3rT2wpS4wwpIlfxBPGNIWXYmFItkOnyqv8XnxZosNFDkDU+X0GcUKSWGTLx oScemypJC5dMxNw54oNMOdSK46a1RR8K+6/gBgAxsIv5mXw32egd1IPI21wPTmsnkCq8 GKY8oM3M25h9eFwt7PzY2j2JYE8Fi9pOcM1/TzzNNrplTllZ6H9PvTaN2IwqCUNj9+LE Ti5YsQjoV43Z6dPRk/HA0UPYvBB90Fj6Qb9ARdqk0Mj9zHobvryC76DIUBw6ufac54zJ s9Zg== 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=JQQNbW8cStAx6+ohPWfDmzYVgImJEYYic+pZzsxiTxQ=; b=kOsSMDqDi5lX1sz49Q08LG1UJbVKrYJ0JvhB/1FGipCmEkBoHkb393+8Dh4H3Mbu5c 6TMQVamrKYwayWGhkwk4vVez7NhJeiKtq/zNTmroj9hpv/pQVnCgMwCB4j6CtsOi0/TG UnY7IIhQLUR8jMBUYTqH9zub6XHpEkQ0KMLCSid7ivadPvQ5F76jovFmXsXUgQHkJxXP PJ/wUhPQA0kxCoLrWIPqcaoFPXgO5JpzbDx7kTL0IWAjiAszrCwy3h6w+j/tEMH+d08x KTYysTA872QAOArEiqzMsxK8cr+ihEKiuwOdU5tEkBg7sgixqDGCLxlfINyP205HDYUV xHdA== X-Gm-Message-State: APjAAAVcZzGhtk1H57YoWY2A0MpzguQsbdF2bIj8b9w8LxGkfnowwCrq B7asbJJZjbtWgyngzU3IZfazCjJPR2kPEqBcbJc= X-Google-Smtp-Source: APXvYqwi1RrpyECzsqZb6dtqISlWTHvLRKJ1K8kpxx0zHPCQt6rnsOias+VktPGTYyulgboNTPHeRdBhHQF/byx4RVc= X-Received: by 2002:a05:6808:f:: with SMTP id u15mr10191097oic.164.1575602698994; Thu, 05 Dec 2019 19:24:58 -0800 (PST) MIME-Version: 1.0 References: <6C2B751E-9402-4ABD-830B-C9099AA97994@fugue.com> In-Reply-To: <6C2B751E-9402-4ABD-830B-C9099AA97994@fugue.com> From: Mark Smith Date: Fri, 6 Dec 2019 14:24:47 +1100 Message-ID: To: Ted Lemon Cc: Lorenzo Colitti , v6ops list , Lorenzo Colitti Content-Type: multipart/alternative; boundary="0000000000002e473c05990097c0" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 03:25:01 -0000 --0000000000002e473c05990097c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 6 Dec 2019, 13:37 Ted Lemon, wrote: > That wasn=E2=80=99t my question. I know how to write one. Can you give me= an > example of one in the wild? It has to be something that gets serious use= . > I'm not sure what the point of your question is. I mentioned my thinking is probably more future and long term because applications would need to be explicitly IPv6 only. I understand that's not going to be many today. The trouble with dual stack applications is that they aren't explicitly saying whether they want or expect IPv4, IPv6 or both from the network. Since what the applications want from the network is ambiguous, it's hard to know if an application would be happy with an IPv6 only network connection. Taking IPv4 away from these ambiguous applications always creates a risk of breaking them. An application that explicitly said "I only want IPv6" doesn't have that risk. > > On Dec 5, 2019, at 17:58, Mark Smith wrote: > > > > =EF=BB=BFOn Fri, 6 Dec 2019 at 12:50, Ted Lemon wrot= e: > >> > >> What=E2=80=99s an ipv6-only application? Normally I would expect an > application to be stack-neutral. > >> > > > > From RFC 3493: > > > > For example, to create an IPv6/TCP socket, applications make the > > call: > > > > s =3D socket(AF_INET6, SOCK_STREAM, 0); > > > > To create an IPv6/UDP socket, applications make the call: > > > > s =3D socket(AF_INET6, SOCK_DGRAM, 0); > > > > > > For example, this application only listens on IPv4 or IPv6, but never > both: > > > > https://github.com/markzzzsmith/replicast > > > > > > Regards, > > Mark. > > > > > >>>> On Dec 5, 2019, at 16:59, Mark Smith wrote: > >>> > >>> =EF=BB=BFOn Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti > wrote: > >>>> > >>>>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith > wrote: > >>>>> > >>>>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the > first IPv4 application started running, then when a host is only running > IPv6 only applications, it would never acquire an IPv4 address because it > wouldn't need one, meaning never try to use DHCPv4 (so would avoid the > link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer > broadcast ARP Requests). > >>>> > >>>> > >>>> Speaking as an OS implementer: how do I know whether an application > is an IPv4 application? > >>>> > >>> > >>> So these are reasonable questions, and they're uncovering some > >>> assumptions and a view point I have: > >>> > >>> - the hosts in question are commonly single homed (and I should know > >>> better *, however I would't be surprised if that is the unstated > >>> assumption of most people when they imagine the scenario being > >>> discussed) > >>> > >>> - the on-demand I'm imagining is inspired by the dial-on-demand that > >>> used to be implemented with ISDN, triggered by IP traffic. ISDN > >>> connection establishment happened quickly enough that it was tolerabl= e > >>> by end-users. If a DHCPv4 transaction occurred within 100 ms, users > >>> will perceive it as instant - "Response Times: The 3 Important Limits= " > >>> - https://www.nngroup.com/articles/response-times-3-important-limits/ > >>> > >>> - IPv6 only applications clearly indicate they're IPv6 only, by only > >>> opening IPv6 sockets. > >>> > >>> This latter point is probably a significant difference between what i= s > >>> being proposed here and what I'm thinking. My thinking is probably > >>> about a passive and longer term mechanism that would result in IPv4 > >>> disappearing over time, rather than an active mechanism that purposel= y > >>> switches IPv4 off on dual stack hosts. > >>> > >>> > >>> Responding to these points for completeness: > >>> > >>>> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do > that. > >>> > >>> They wouldn't be IPv6 Only applications. > >>> > >>> > >>>> When it creates an IPv4 socket? But what if it's creating an IPv4 > socket for the purpose of connecting to another network on the system > (e.g., cellular data) that does have IPv4? > >>> > >>> Yes, this would be an issue with what I was describing. > >>> > >>> What I'm thinking about would probably more result in "IPv6 Only" > >>> being a host level status on a host, covering all interfaces (1 or > >>> many), rather than an interface status. In other words, if a host is > >>> only currently running IPv6 Only applications, then there is no need > >>> for any IPv4 addresses on any of its interfaces. > >>> > >>> > >>>> When it does a connect() on an IPv4 socket? But what if that's just = a > happy eyeballs stack that is using IPv4 because it might be available? > >>> > >>> As above, not an IPv6 Only application if trying to use HE. > >>> > >>> > >>>> What if the app knows it needs IPv4 and will refuse to do any > networking if it doesn't find an IPv4 address on the system? > >>> > >>> Not an IPv6 Only application. > >>> > >>> > >>> I see value in both applications being explicit about what Internet > >>> Protocol they want to use (e.g. on demand addressing per above), and > >>> also being agnostic about it. > >>> > >>> > >>> > >>> Regards, > >>> Mark. > >>> > >>> > >>> > >>> (* "The Rapid Rise of the Mobile Multi-Homed Host" - > >>> > https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%= 20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf > ) > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > --0000000000002e473c05990097c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 6 Dec 2019, 13:37 Ted Lemon, <mellon@fugue.co= m> wrote:
That wasn=E2=80=99= t my question. I know how to write one. Can you give me an example of one i= n the wild?=C2=A0 It has to be something that gets serious use.

I'm not= sure what the point of your question is.

=
I mentioned my thinking is probably more future and long = term because applications would need to be explicitly IPv6 only. I understa= nd that's not going to be many today.

=
The trouble with dual stack applications is that they are= n't explicitly saying whether they want or expect IPv4, IPv6 or both fr= om the network.

Since wh= at the applications want from the network is ambiguous, it's hard to kn= ow if an application would be happy with an IPv6 only network connection.

Taking IPv4 away from the= se ambiguous applications always creates a risk of breaking them.

An application that explicitly sa= id "I only want IPv6" doesn't have that risk.



> On Dec 5, 2019, at 17:58, Mark Smith <markzzzsmith@g= mail.com> wrote:
>
> =EF=BB=BFOn Fri, 6 Dec 2019 at 12:50, Ted Lemon <mellon@fu= gue.com> wrote:
>>
>> What=E2=80=99s an ipv6-only application?=C2=A0 Normally I would ex= pect an application to be stack-neutral.
>>
>
> From RFC 3493:
>
> For example, to create an IPv6/TCP socket, applications make the
>=C2=A0 =C2=A0call:
>
>=C2=A0 =C2=A0 =C2=A0 s =3D socket(AF_INET6, SOCK_STREAM, 0);
>
>=C2=A0 =C2=A0To create an IPv6/UDP socket, applications make the call:<= br> >
>=C2=A0 =C2=A0 =C2=A0 s =3D socket(AF_INET6, SOCK_DGRAM, 0);
>
>
> For example, this application only listens on IPv4 or IPv6, but never = both:
>
> https://github.com/markzzzsmith/= replicast
>
>
> Regards,
> Mark.
>
>
>>>> On Dec 5, 2019, at 16:59, Mark Smith <ma= rkzzzsmith@gmail.com> wrote:
>>>
>>> =EF=BB=BFOn Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti <lorenzo@google.com> wrote:
>>>>
>>>>> On Thu, Dec 5, 2019 at 9:53 AM Mark Smith <markzzzsmith@gmail.com> wrote:
>>>>>
>>>>> If hosts only acquired IPv4 addresses via DHCPv4 based= on when the first IPv4 application started running, then when a host is on= ly running IPv6 only applications, it would never acquire an IPv4 address b= ecause it wouldn't need one, meaning never try to use DHCPv4 (so would = avoid the link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid lin= k-layer broadcast ARP Requests).
>>>>
>>>>
>>>> Speaking as an OS implementer: how do I know whether an ap= plication is an IPv4 application?
>>>>
>>>
>>> So these are reasonable questions, and they're uncovering = some
>>> assumptions and a view point I have:
>>>
>>> - the hosts in question are commonly single homed (and I shoul= d know
>>> better *, however I would't be surprised if that is the un= stated
>>> assumption of most people when they imagine the scenario being=
>>> discussed)
>>>
>>> - the on-demand I'm imagining is inspired by the dial-on-d= emand that
>>> used to be implemented with ISDN, triggered by IP traffic. ISD= N
>>> connection establishment happened quickly enough that it was t= olerable
>>> by end-users. If a DHCPv4 transaction occurred within 100 ms, = users
>>> will perceive it as instant - "Response Times: The 3 Impo= rtant Limits"
>>> - https://www.nngroup.com/articles/response-times-3-important-limits/=
>>>
>>> - IPv6 only applications clearly indicate they're IPv6 onl= y, by only
>>> opening IPv6 sockets.
>>>
>>> This latter point is probably a significant difference between= what is
>>> being proposed here and what I'm thinking. My thinking is = probably
>>> about a passive and longer term mechanism that would result in= IPv4
>>> disappearing over time, rather than an active mechanism that p= urposely
>>> switches IPv4 off on dual stack hosts.
>>>
>>>
>>> Responding to these points for completeness:
>>>
>>>> When it calls getaddrinfo() with AF_UNSPEC? Pretty much al= l apps do that.
>>>
>>> They wouldn't be IPv6 Only applications.
>>>
>>>
>>>> When it creates an IPv4 socket? But what if it's creat= ing an IPv4 socket for the purpose of connecting to another network on the = system (e.g., cellular data) that does have IPv4?
>>>
>>> Yes, this would be an issue with what I was describing.
>>>
>>> What I'm thinking about would probably more result in &quo= t;IPv6 Only"
>>> being a host level status on a host, covering all interfaces (= 1 or
>>> many), rather than an interface status. In other words, if a h= ost is
>>> only currently running IPv6 Only applications, then there is n= o need
>>> for any IPv4 addresses on any of its interfaces.
>>>
>>>
>>>> When it does a connect() on an IPv4 socket? But what if th= at's just a happy eyeballs stack that is using IPv4 because it might be= available?
>>>
>>> As above, not an IPv6 Only application if trying to use HE. >>>
>>>
>>>> What if the app knows it needs IPv4 and will refuse to do = any networking if it doesn't find an IPv4 address on the system?
>>>
>>> Not an IPv6 Only application.
>>>
>>>
>>> I see value in both applications being explicit about what Int= ernet
>>> Protocol they want to use (e.g. on demand addressing per above= ), and
>>> also being agnostic about it.
>>>
>>>
>>>
>>> Regards,
>>> Mark.
>>>
>>>
>>>
>>> (* "The Rapid Rise of the Mobile Multi-Homed Host" -=
>>> https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%2= 0P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf) >>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/m= ailman/listinfo/v6ops
--0000000000002e473c05990097c0-- From nobody Thu Dec 5 23:14:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161A2120096; Thu, 5 Dec 2019 23:14:48 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xBUPW1VMuWC; Thu, 5 Dec 2019 23:14:47 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438A412004D; Thu, 5 Dec 2019 23:14:47 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id t5so2329032qvs.5; Thu, 05 Dec 2019 23:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TQKe12wr+gFrDba6yf8tj9AHdDjmQlyWjWUypleZBRg=; b=GSeEE4upcHa56VyKfDwpoUd+//Fft1FrY6FqqQtgbxHC9k2nIBMK3eK90J0TIcyIAN bg7lQvd3pgjd0RE+QewvlijVfTYlQzE10glAUIAMveI0VcUU4glB/eWdZmCBFz8hE/iz G3lzD6EMQy9rG4LKjVE7icmvVtz/lIcwDEO7TUbOj4XcLCLRBIVDKfuYv9sXXV3k5y+K 5RLspl/qqa/5AJVf2SFUu6dbXOfcemXiZh0JISRrBlwyGZwypsEegHaAqwfqxeDh4do/ Oj8SGoESWJldGBqNbfKjOreswjPP+6r0+xykiZpuVFEpWzFJx3kTyICPG3WLqMH3Qeia xRyg== 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=TQKe12wr+gFrDba6yf8tj9AHdDjmQlyWjWUypleZBRg=; b=hD7ne+bbaA/lsnlg7xsltLv5nFNn6KgduFlEnUnAQVKUxtcjjgCwYx7XMYh1Xux63m hhuleBBkzdxyXGks0nrBG+lnbc+vZy1HHOrOlTp56ako2HUdZ7x9KVe2tWcWsn0xKfsI yq1rY6+3IbTsSb547WSn3d1/Q+jeGZbJUq/3NGclzAgggCUpJLHIxOR6QRGugiNevdtS VQ8Cas8JKCkFy0XL3zaqoSDiwOlIkD7rOneNyV0LcETZoFz9qWt2ja8q7K+wefUcUWXQ crVFOIV8x6mSdYBvrmmSEAiZ+d+8CtNvBj2T9mXYietWIan1cfsvei3XgJ6HPYfFJ/Jm IAWg== X-Gm-Message-State: APjAAAVq9UaXU6rGwMhZzmSH31AE4LN7s56YeBAEdoZDjwzJY7TxK0DA CuY1+BCnLq30fzcp7CzVupoLCbEVv1BP8s/+q+8= X-Google-Smtp-Source: APXvYqwnjKlqTEk0qC8PJ/JuPw6v+MlB3UAvXSIjRlLrD/vo2DC8rbfFSwwu9bmvYG6g2vKHQPU44B08Dz8uoeUlv7Y= X-Received: by 2002:a0c:ad35:: with SMTP id u50mr11603002qvc.158.1575616486030; Thu, 05 Dec 2019 23:14:46 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Jen Linkova Date: Fri, 6 Dec 2019 18:14:34 +1100 Message-ID: To: David Farmer Cc: Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 07:14:48 -0000 On Thu, Dec 5, 2019 at 12:09 PM David Farmer wrote: >> > Also, is there any reason that 0.0.0.0 shouldn't be the address retund= ed by a server "if the IPv6-only Preferred option is present in the Paramet= er Request List received from the client and the corresponding DHCP pool is= explicitly configured as belonging to an IPv6-mostly network segment" as d= iscussed in Section 3.3? >> >> We discussed that but some concerns were raised - allegedly it might >> make some DHCP-snooping switches very unhappy. > > > If that is really the case then I think some discussion on selecting the = address returned is probably needed in the draft. The draft currently suggests that the server is configured with a dedicated IPv4 address per pool for this purpose: "If the pool is explicitly configured with a dedicated IPv4 address to be returned to IPv6-only capable clients the server MUST specify that address as the client's network address and MUST NOT verify its uniqueness. Otherwise the server SHOULD follow the recommendations in [RFC2131]. The client is not expected to use that IPv4 address so if the client responds with the DHCPREQUEST message for that address the server SHOULD respond with DHCPNAK. " If there is no dedicated address, I guess it does not really matter what address from the pool is returned. Or am I missing anything? --=20 SY, Jen Linkova aka Furry From nobody Thu Dec 5 23:21:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE881200D5 for ; Thu, 5 Dec 2019 23:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ctKQmD-XvTu7 for ; Thu, 5 Dec 2019 23:21:33 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD3C120096 for ; Thu, 5 Dec 2019 23:21:33 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id b15so5437400iln.3 for ; Thu, 05 Dec 2019 23:21:33 -0800 (PST) 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=c9VqvQi4T4pTP9fkqwel3PUHk6VfRMwQWHQPlTCoqeY=; b=VsqdmjdbC3l8GhdAMHTrtumPBCg7GqWMr/GQNcR3KRaCE0qRAWtY2ImwnY8fyxAIZY jITzbJTe5+luN6lCzsrqlWyybmzvlGLu+BSSycFMnwKgxoT3adBCBJJ2JVlKHBxl2X5T gp1iFdAjU5qFvXkRIj3cZmYJmQj8JgPoLlpFy78GLvD9bO1/UHpHEWLYl+c83/SEp5XY JqwM1RoQcDs0XdlluHCK8ImC1UInE0cG26j1yc98ldLkva+KbWyPqY2rYcu9dbtlWBRt cyWim7I9Fq1B5w+BKfHy/cD+GImk3eslcKff5O+RyLXvA2EnqCPW3vH6JUtAwkckVx7L lOEA== 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=c9VqvQi4T4pTP9fkqwel3PUHk6VfRMwQWHQPlTCoqeY=; b=r/UYqUnao1G1cCm2uTOUjOLekDr52MQIjLkKVPYHc3JHge2GNzUyJUdiyXAp7ylVnZ Och67Ykz5CJW+S4M4M9CVxdnxBjF+5nCw5K7hl75Zkf3OCr1M1nmjOSsUiv4ZavoD0pl GJ+hT0vluLbINcEFXXvwyBoadZ0y+fCHeEX4QzsMyigNpqVmsSvdcULgKpRzE36bdCdQ lgIvFvar8mbmywHxLKdT41aoyOTDn73Y2M9VKTqgDz3kwMNCFzbL4p+OVnonaMTtLT+8 ZsGHp77hzAVpxJl6LyopAbf6ZDAtaZPIlEXN+K24KLU67Esq/SToOO2pTaGMpy6HNUdY RsJA== X-Gm-Message-State: APjAAAUS4OWwNfw4cYJYDR2/h2zI1TmH3pFlhxlWHr+xCBay2CWeBGbP HRLZFzGyB4Hnn+FoEsJiY60xw7PwbqLNkhI5C4VDEQ== X-Google-Smtp-Source: APXvYqwIRNOD1hE8b9K6C5zD9QPssHH5H04Wmg9o6qPooeItII7xIKqyX3ZlLlbtQrkjfvIP++XqppuFfoi4ZTW+l7g= X-Received: by 2002:a92:6e09:: with SMTP id j9mr10433647ilc.178.1575616892149; Thu, 05 Dec 2019 23:21:32 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Lorenzo Colitti Date: Fri, 6 Dec 2019 16:21:19 +0900 Message-ID: To: Jen Linkova , Tomek Mrugalski Cc: David Farmer , Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org Content-Type: multipart/alternative; boundary="00000000000028fe37059903e5fd" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 07:21:35 -0000 --00000000000028fe37059903e5fd Content-Type: text/plain; charset="UTF-8" On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova wrote: > "If the pool is explicitly configured with a dedicated IPv4 > address to be returned to IPv6-only capable clients the server MUST > specify that address as the client's network address and MUST NOT > verify its uniqueness. > That seems difficult to implement on the server. Why not just return a normal OFFER from the pool? That way, if something unexpected happens and the client sends a DHCPREQUEST for it, the server can hand it out as normal. The alternative is risky. If the server uses a bogus OFFER value, and some client requests it and the server hands it out, that creates the possibility for misconfiguration or bugs to create really bad outcomes where multiple hosts have the same IP address, or some things on the network (e.g., snooping switches) think that multiple hosts have the same IP address. +Tomek Mrugalski any thoughts on whether this can be implemented easily and reliably on the server side? --00000000000028fe37059903e5fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 6, 2019 at 4:14 PM Jen Linkov= a <furry13@gmail.com> wrote:=
"If the pool is explicitly configured with a dedicated IPv= 4
=C2=A0 =C2=A0address to be returned to IPv6-only capable clients the server= MUST
=C2=A0 =C2=A0specify that address as the client's network address and M= UST NOT
=C2=A0 =C2=A0verify its uniqueness.

Tha= t seems difficult to implement on the server. Why not just return a normal = OFFER from the pool? That way, if something unexpected happens and the clie= nt sends a DHCPREQUEST for it, the server can hand it out as normal.
<= div>
The alternative is risky. If the server uses a bogus OFF= ER value, and some client requests it and the server hands it out, that cre= ates the possibility for misconfiguration or bugs to create really bad outc= omes where multiple hosts have the same IP address, or some things on the n= etwork (e.g., snooping switches) think that multiple hosts have the same IP= address.=C2=A0+Tomek Mrugalski=C2= =A0any thoughts on whether this can be implemented easily and reliably on t= he server side?
--00000000000028fe37059903e5fd-- From nobody Fri Dec 6 00:01:19 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1A120220; Fri, 6 Dec 2019 00:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRTzLvhFtQh3; Fri, 6 Dec 2019 00:01:11 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E99212000F; Fri, 6 Dec 2019 00:01:11 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 47TlQY4Wngz102g; Fri, 6 Dec 2019 09:01:09 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 47TlQY38rZzFpX6; Fri, 6 Dec 2019 09:01:09 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 6 Dec 2019 09:01:09 +0100 From: To: Lorenzo Colitti CC: Jen Linkova , =?utf-8?B?QmrDuHJuIE1vcms=?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVq3bo0EzcIgM90k+qjQhPGFF0raess/8A Date: Fri, 6 Dec 2019 08:01:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E5E90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E5E90OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 08:01:13 -0000 --_000_787AE7BB302AE849A7480A190F8B9330313E5E90OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCkVudm95w6kgOiBq ZXVkaSA1IGTDqWNlbWJyZSAyMDE5IDE1OjE5DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9P TE4NCkNjIDogSmVuIExpbmtvdmE7IEJqw7hybiBNb3JrOyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3Bz IExpc3Q7IGRyYWZ0LWxpbmstZGhjLXY2b25seUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW2RoY3dn XSBJUHY2LU9ubHkgUHJlZmVycmVkIERIQ1B2NCBvcHRpb24NCg0KT24gVGh1LCBEZWMgNSwgMjAx OSBhdCAxMDoyNCBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KSG9zdHMgZG8gbm90IGRvIHRoaXMgdG9k YXksIGFuZCBJIGRvbid0IHRoaW5rIHRoZXkgd2lsbCBzdGFydCBkb2luZyBzby4gVGhlIHJlYXNv biBpcyB0aGF0IHRoZXkgY2Fubm90IHRlbGwgd2hldGhlciBhbm90aGVyIHByb3RvY29sIHdpbGwg c3RhcnQgd29ya2luZy4gSWYgdGhleSB3YWl0IHh4eCBtcyB0byBtYWtlIHN1cmUgdGhlIG90aGVy IHByb3RvY29sIGNvbWVzIHVwLCB0aGV5IGFyZSBzbG93aW5nIGRvd24gYWxsIGNvbm5lY3Rpb25z IHRvIHNpbmdsZS1zdGFjayBuZXR3b3JrcyBieSB4eHggbXMsIG1ha2luZyB0aGVpciB1c2VycyB1 bmhhcHB5Lg0KDQpbTWVkXSBEbyB5b3UgbWVhbiB0aGF0IGNsaWVudHMgdGhhdCByZWNlaXZlIHRo ZSBzaWduYWwgdG8gcmVsZWFzZSBJUHY0IGNvbmZpZ3VyYXRpb24gd2lsbCBtYWtlIHRoZSB1c2Vy cyB1bmhhcHB5IGFueXdheSBiZWNhdXNlIHRoZXkgd2lsbCBuZWVkIHRvIHdhaXQgZm9yIHRoZSBw cmVmNjQgdG8gcHJvcGVybHkgd29yaz8NCg0KV2VsbCwgdGhhdCdzIHRoZSBpbnRlbnQgb2YgdGhl IHByZWY2NCBSQSBvcHRpb24uIFRoYXQgYWxsb3dzIHRoZSBwcmVmNjQgdG8gYmUgY29tbXVuaWNh dGVkIGluIHRoZSBzYW1lIHBhY2tldCBhcyB0aGUgcmVzdCBvZiB0aGUgY29uZmlndXJhdGlvbiBw YXJhbWV0ZXJzLg0KW01lZF0gSWYgdGhlcmUgaXMgbm8gZGVsYXkgdGhlbiwgdGhlIHNpZ25hbHMg KHByZWY2NCBwcmVzZW5jZSwgdjYtb25seSBwcmVzZW5jZSkgYXJlIHJlZHVuZGFudC4gTm8/DQoN Ck5vdGUgdGhhdCBJUHY2IGhhcyBidWlsdC1pbiBkZWxheXMgaW4gdGhlIHByb3RvY29sIGl0c2Vs ZiAoREFEIGZvciB0aGUgbGluay1sb2NhbCBhZGRyZXNzOyB2YXJpb3VzIHJhbmRvbWl6ZWQgZGVs YXlzKSB0aGF0IG1ha2UgaXQgdmVyeSBkaWZmaWN1bHQgdG8gZ2V0IGFueXRoaW5nIGRvbmUgYmVm b3JlIGF0IGxlYXN0IDEtMiBzZWNvbmRzIGhhdmUgcGFzc2VkLiBIb3N0cyB0aGF0IGtub3cgdGhh dCA3MCUgb2YgbmV0d29ya3MgYXJlIElQdjQtb25seSB3aWxsIG5vdCB3YW50IHRvIHdhaXQgMS0y IHNlY29uZHMgdG8gY29ubmVjdCB0byB0aG9zZSBuZXR3b3Jrcy4NCg0KW01lZF0gSW4gdGhhdCBj YXNlLCB3aGF0IGlzIHRoZSBiZW5lZml0IGZvciB0aGUgaG9zdCB0byBpbmRpY2F0ZSBpdHMgaXB2 Ni1vbmx5IG1vZGUgc3VwcG9ydD8NCg0KVGhlIG9wdGlvbiBpbXByb3ZlcyB0aGUgc2l0dWF0aW9u IGJ5IGFsbG93aW5nIHRoZSBob3N0IHRvIHdhaXQgZm9yIElQdjYgb25seSBpZiBpdCBpcyBleHBl Y3RlZCB0byBleGlzdC4NCltNZWRdIFRoZSBob3N0IGNhbiDigJx3YWl04oCdIHdpdGhvdXQgcmVx dWlyaW5nIHRoZSBvcHRpb24uIFRoZSBrZXkgcG9pbnQgaXMgdGhhdCBhbiBhZG1pbmlzdHJhdG9y IHNldHMg4oCcaXB2Ni1tb2Rl4oCdIHN1cHBvcnRlZC4NCg0KSG9zdHMgdGhhdCBpbXBsZW1lbnQg dGhlIG9wdGlvbiBhbGxvdyBuZXR3b3JrcyB0byBwcm92aWRlIGJldHRlciBzZXJ2aWNlIGFuZCBj cmVhdGUgYW4gaW5jZW50aXZlIGZvciBuZXR3b3JrcyB0byBzdXBwb3J0IElQdjYNCltNZWRdIEni gJltIG5vdCBzdXJlIGFib3V0IHRoaXMgYmVuZWZpdCBmb3IgdGhlIE5BVDY0IGNhc2UgYXMgbWFu eSBmZWF0dXJlcyBkZXBlbmRzIG9uIHRoZSBkaXNjb3Zlcnkgb2YgdGhlIHByZWZpeDY0Lg0KDQpU aGF04oCZcyBzYWlkLCBJIGRvIHNlZSBhIHBvc3NpYmxlIHZhbHVlIGZvciB0aGUgbmV0d29yayBz aWRlIGJ1dCBmb3Igb3RoZXIgSVB2Ni1vbmx5IGRlcGxveW1lbnRzOg0KDQoNCsK3ICAgICAgICAg Q1BFIGluIERTLUxpdGUgbW9kZQ0KDQrCtyAgICAgICAgIENQRSBpbiBBK1AgbW9kZQ0KDQpJZiBk cy1saXRlIChvciBhK3ApIG1vZGUgaXMgZXhwbGljaXRseSBlbmFibGVkIChtYW5hZ2VkIENQRSks IERIQ1B2NCB3b27igJl0IGJlIGlzc3VlZC4gSW4gYWRkaXRpb24sIGlmIHRoZSBDUEUgaXMgZHMt bGl0ZSBhbmQgYStwIGNvbXBsaWFudCwgdGhlbiBSRkM4MDI2IHdpbGwgYmUgdXNlZC4gTm8gbmVl ZCBmb3IgYWRkaXRpb25hbCBzaWduYWwuDQoNCk5vdywgaWYgdGhlIENQRSBpcyBkcy1saXRlL2Er cCBjYXBhYmxlIChub24tbWFuYWdlZCBDUEUpIGJ1dCBkb2VzIG5vdCBrbm93IGlmIHRoZSBuZXR3 b3JrIGlzIGRzLWxpdGUvYStwIGNhcGFibGUsIHRoZSBDUEUgd2lsbCBpc3N1ZSBib3RoIERIQ1B2 NCBhbmQgREhDUHY2IHJlcXVlc3RzLiBJZiBubyDigJxjaGVja3PigJ0gYXJlIGltcGxlbWVudGVk IGF0IHRoZSBESENQdjQgc2VydmVyIHNpZGUsIHRoZSBDUEUgbWF5IGJlIGFzc2lnbmVkIGFuIElQ djQgYWRkcmVzcyBpbiBhZGRpdGlvbiB0byByZWNlaXZpbmcgT1BUSU9OX0FGVFJfTkFNRS4gVGhl IENQRSB3aWxsIG5lZWQgdG8gcmVsZWFzZSB0aGUgSVB2NCBhZGRyZXNzLg0KDQpXaXRoIHlvdXIg b3B0aW9uLCB0aGUgc2l0dWF0aW9uIHdpbGwgYmUgbXVjaCBtb3JlIHNpbXBsZSBhbmQgdGhlIHNl cnZlciB3aWxsIGJlIHJldHVybmluZyBhbiBhZGRyZXNzIGluIDE5Mi4wLjAuMC8yOSAoUkZDNjMz MywgU2VjdGlvbiA1LjcpLg0KDQpDaGVlcnMsDQpNZWQNCg== --_000_787AE7BB302AE849A7480A190F8B9330313E5E90OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1 cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDY0ODM0ODk1Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5NTU2OTQ1MzQgMTU2OTYy Mjk1MiA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5 NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5NDIxODI3OTI7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3ODUwODA5MzQgLTMyNDI2NTAw MiA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2 Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkOw0KCW1zby1hbnNpLWZv bnQtc3R5bGU6aXRhbGljO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9y ZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IGpldWRpIDUgZMOpY2VtYnJlIDIwMTkgMTU6MTk8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEpl biBMaW5rb3ZhOyBCasO4cm4gTW9yazsgZGhjd2dAaWV0Zi5vcmc7IFY2IE9wcyBMaXN0OyBkcmFm dC1saW5rLWRoYy12Nm9ubHlAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBb ZGhjd2ddIElQdjYtT25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMg NSwgMjAxOSBhdCAxMDoyNCBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I b3N0cyBkbyBub3QgZG8gdGhpcyB0b2RheSwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhleSB3aWxsIHN0 YXJ0IGRvaW5nIHNvLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhleSBjYW5ub3QgdGVsbCB3aGV0aGVy IGFub3RoZXIgcHJvdG9jb2wgd2lsbCBzdGFydCB3b3JraW5nLiBJZiB0aGV5IHdhaXQgeHh4IG1z IHRvIG1ha2UNCiBzdXJlIHRoZSBvdGhlciBwcm90b2NvbCBjb21lcyB1cCwgdGhleSBhcmUgc2xv d2luZyBkb3duIGFsbCBjb25uZWN0aW9ucyB0byBzaW5nbGUtc3RhY2sgbmV0d29ya3MgYnkgeHh4 IG1zLCBtYWtpbmcgdGhlaXIgdXNlcnMgdW5oYXBweS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXQ0K PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHlv dSBtZWFuIHRoYXQgY2xpZW50cyB0aGF0IHJlY2VpdmUgdGhlIHNpZ25hbCB0byByZWxlYXNlIElQ djQgY29uZmlndXJhdGlvbiB3aWxsIG1ha2UgdGhlIHVzZXJzIHVuaGFwcHkgYW55d2F5IGJlY2F1 c2UgdGhleSB3aWxsIG5lZWQgdG8gd2FpdCBmb3IgdGhlIHByZWY2NA0KIHRvIHByb3Blcmx5IHdv cms/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsLCB0aGF0 J3MgdGhlIGludGVudCBvZiB0aGUgcHJlZjY0IFJBIG9wdGlvbi4gVGhhdCBhbGxvd3MgdGhlIHBy ZWY2NCB0byBiZSBjb21tdW5pY2F0ZWQgaW4gdGhlIHNhbWUgcGFja2V0IGFzIHRoZSByZXN0IG9m IHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0gSWYg dGhlcmUgaXMgbm8gZGVsYXkgdGhlbiwgdGhlIHNpZ25hbHMgKHByZWY2NCBwcmVzZW5jZSwgdjYt b25seSBwcmVzZW5jZSkgYXJlIHJlZHVuZGFudC4gTm8/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdGUgdGhhdCBJUHY2IGhhcyBidWlsdC1pbiBkZWxh eXMgaW4gdGhlIHByb3RvY29sIGl0c2VsZiAoREFEIGZvciB0aGUgbGluay1sb2NhbCBhZGRyZXNz OyB2YXJpb3VzIHJhbmRvbWl6ZWQgZGVsYXlzKSB0aGF0IG1ha2UgaXQgdmVyeSBkaWZmaWN1bHQg dG8gZ2V0IGFueXRoaW5nDQogZG9uZSBiZWZvcmUgYXQgbGVhc3QgMS0yIHNlY29uZHMmbmJzcDto YXZlIHBhc3NlZC4gPC9zcGFuPkhvc3RzIHRoYXQga25vdyB0aGF0IDcwJSBvZiBuZXR3b3JrcyBh cmUgSVB2NC1vbmx5IHdpbGwgbm90IHdhbnQgdG8gd2FpdCAxLTIgc2Vjb25kcyB0byBjb25uZWN0 IHRvIHRob3NlIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEluIHRoYXQgY2FzZSwgd2hhdCBpcyB0aGUgYmVuZWZpdCBm b3IgdGhlIGhvc3QgdG8gaW5kaWNhdGUgaXRzIGlwdjYtb25seSBtb2RlIHN1cHBvcnQ/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb3B0aW9uIGltcHJvdmVz IHRoZSBzaXR1YXRpb24gYnkgYWxsb3dpbmcgdGhlIGhvc3QgdG8gd2FpdCBmb3IgSVB2NiBvbmx5 IGlmIGl0IGlzIGV4cGVjdGVkIHRvIGV4aXN0LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0gVGhlIGhvc3QgY2FuIOKAnHdhaXTigJ0gd2l0 aG91dCByZXF1aXJpbmcgdGhlIG9wdGlvbi4gVGhlIGtleSBwb2ludCBpcyB0aGF0IGFuIGFkbWlu aXN0cmF0b3Igc2V0cyDigJxpcHY2LW1vZGXigJ0gc3VwcG9ydGVkLiAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SG9zdHMgdGhh dCBpbXBsZW1lbnQgdGhlIG9wdGlvbiBhbGxvdyBuZXR3b3JrcyB0byBwcm92aWRlIGJldHRlciBz ZXJ2aWNlIGFuZCBjcmVhdGUgYW4gaW5jZW50aXZlIGZvciBuZXR3b3JrcyB0byBzdXBwb3J0IElQ djY8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5bTWVkXSBJ4oCZbSBub3Qgc3VyZSBhYm91dCB0aGlzIGJlbmVmaXQgZm9yIHRoZSBOQVQ2 NCBjYXNlIGFzIG1hbnkgZmVhdHVyZXMgZGVwZW5kcyBvbiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBw cmVmaXg2NC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhdOKAmXMgc2FpZCwgSSBkbyBzZWUgYSBwb3NzaWJsZSB2YWx1ZSBmb3IgdGhl IG5ldHdvcmsgc2lkZSBidXQgZm9yIG90aGVyIElQdjYtb25seSBkZXBsb3ltZW50czoNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DUEUgaW4gRFMtTGl0ZSBtb2RlICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkNQRSBpbiBBJiM0MztQIG1vZGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgZHMtbGl0ZSAob3IgYSYjNDM7cCkgbW9kZSBp cyBleHBsaWNpdGx5IGVuYWJsZWQgKG1hbmFnZWQgQ1BFKSwgREhDUHY0IHdvbuKAmXQgYmUgaXNz dWVkLiBJbiBhZGRpdGlvbiwgaWYgdGhlIENQRSBpcyBkcy1saXRlIGFuZCBhJiM0MztwIGNvbXBs aWFudCwgdGhlbiBSRkM4MDI2DQogd2lsbCBiZSB1c2VkLiBObyBuZWVkIGZvciBhZGRpdGlvbmFs IHNpZ25hbC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ob3csIGlmIHRoZSBDUEUgaXMgZHMtbGl0ZS9hJiM0MztwIGNhcGFibGUgKG5vbi1t YW5hZ2VkIENQRSkgYnV0IGRvZXMgbm90IGtub3cgaWYgdGhlIG5ldHdvcmsgaXMgZHMtbGl0ZS9h JiM0MztwIGNhcGFibGUsIHRoZSBDUEUgd2lsbCBpc3N1ZSBib3RoIERIQ1B2NCBhbmQgREhDUHY2 DQogcmVxdWVzdHMuIElmIG5vIOKAnGNoZWNrc+KAnSBhcmUgaW1wbGVtZW50ZWQgYXQgdGhlIERI Q1B2NCBzZXJ2ZXIgc2lkZSwgdGhlIENQRSBtYXkgYmUgYXNzaWduZWQgYW4gSVB2NCBhZGRyZXNz IGluIGFkZGl0aW9uIHRvIHJlY2VpdmluZyBPUFRJT05fQUZUUl9OQU1FLiBUaGUgQ1BFIHdpbGwg bmVlZCB0byByZWxlYXNlIHRoZSBJUHY0IGFkZHJlc3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggeW91ciBvcHRpb24sIHRoZSBz aXR1YXRpb24gd2lsbCBiZSBtdWNoIG1vcmUgc2ltcGxlIGFuZCB0aGUgc2VydmVyIHdpbGwgYmUg cmV0dXJuaW5nIGFuIGFkZHJlc3MgaW4gMTkyLjAuMC4wLzI5IChSRkM2MzMzLCBTZWN0aW9uIDUu NykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lZDxiPjxpPjxvOnA+PC9vOnA+PC9p PjwvYj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330313E5E90OPEXCAUBMA2corp_-- From nobody Fri Dec 6 02:04:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C8D120096 for ; Fri, 6 Dec 2019 02:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 nQTlDJeEMy5m for ; Fri, 6 Dec 2019 02:04:10 -0800 (PST) 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 37D5D12008A for ; Fri, 6 Dec 2019 02:04:10 -0800 (PST) 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 m1idAT1-0000L9C; Fri, 6 Dec 2019 11:04:07 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-reply-to: Your message of "Fri, 6 Dec 2019 09:26:07 +1100 ." Date: Fri, 06 Dec 2019 11:04:07 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 10:04:12 -0000 >I'm an operator who could not wait to implement that draft (and I'm >aware of at least one other operator who might be interested). >Maybe I'm not creative enough but all other options of incremental >deployment of IPv6-only I've come up with are much more ugly >(doubling the number of SSIDs/VLANs or having a portal when users have to >request IPv4 so their MACs are whitelisted etc). Can you describe why offering both NAT64 and native IPv4 on the same lan doesn't work? Note that I don't have a strong opinion on what would be enough demand from operators. It seems to me that running both dual stack and NAT64 on the same network is bad from an operational point of view. But if people want to do it anyway, then it is fine with me. One thing that worries me a bit is that with this option the host signals that it doesn't need an IPv4 address if there is NAT64. There are two things that can go wrong: the network provides the NAT64 transation prefix in a way that the host doesn't understand. The second thing, what if some other IPv4aaS technology becomes popular, do we need a new option for every IPv4aaS technology? From nobody Fri Dec 6 02:10:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5EA12009C for ; Fri, 6 Dec 2019 02:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYMnUJ_DhPvy for ; Fri, 6 Dec 2019 02:10:45 -0800 (PST) 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 3720F12008A for ; Fri, 6 Dec 2019 02:10:45 -0800 (PST) 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 m1idAZO-0000GcC; Fri, 6 Dec 2019 11:10:42 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <5876B53D-01D1-4689-8FFA-25320EA265DD@fugue.com> In-reply-to: Your message of "Fri, 6 Dec 2019 12:57:48 +1100 ." Date: Fri, 06 Dec 2019 11:10:42 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 10:10:46 -0000 > >From RFC 3493: > > For example, to create an IPv6/TCP socket, applications make the > call: > > s = socket(AF_INET6, SOCK_STREAM, 0); Technically that does not create an IPv6/TCP socket. See Section 3.7, in RFC 3493. From nobody Fri Dec 6 02:37:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E101200F5 for ; Fri, 6 Dec 2019 02:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 5jpYjWDgpvYE for ; Fri, 6 Dec 2019 02:37:29 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9670A1200F1 for ; Fri, 6 Dec 2019 02:37:29 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id z12so5808935iln.11 for ; Fri, 06 Dec 2019 02:37:29 -0800 (PST) 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=j3CH4kWWyK/TBw/U9RyjDEZxCYrZMkshh75M/ynGF5I=; b=HiAOIRrz2gYYJSlBRp6s0hK+/czGfgxjqX7sFK7OfgBkFeDhG30M0xBD9ZHrzie8nt T5r23exmClyqtVb7snhkhzAtQcVH4JujmKU3oSPNDAQdobPFQIcItcNAcaXfX4LyMc6g PnLhEI+eQG6Ci9Ph3AdMydyrdq5ZiegnUx3g/UUmuZzT88uOYlGY5Fp50V+cCBfH0nRB jz84ZqJGvDrAwD2Ax2azGmP48qipP3F5A+h/Z3nBJyqEGo+Q0CYZxiiI0QkeOCccDw99 sMZFUku1W9/QKLSzg8K0Npx3qwtOdEefs6AmqHbQ038R+kzoKrm+D5LTfVRwT334hu+2 qXyQ== 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=j3CH4kWWyK/TBw/U9RyjDEZxCYrZMkshh75M/ynGF5I=; b=jBybPtnCubAjA33yAHme/ll7CitYVjgeWGn6Y17Vjpdrc8pkAgk5bmRYOlnEqgXkTN yuBA2LiFB8CfK49WRgTFsFd1LU++UfiMMOGeQuxFQnmL5rbJdouB4JdXbLSkZN+8Galm iWeFjw0Vbsco/rlZemWo4EayG32ubTZzCJy+6aGFlniWluDCAC5IsZKo+osxW5UWfNwT XhP98OrByBdMkWep9yhK5XAkq3mFcb2f7scna+Ejp+i4DpImBt4juwwalu4rPf+aRZPz Nfc/UY84nJfhZ83jjDPNiKfWoAeodFWNrQ+/kkvo4RnQ3VbgU6taPzlY6qaNUIDcJOGT Fl8Q== X-Gm-Message-State: APjAAAW1KUJicIn0Ht2zNq5GVJmgWChVFGGAbuTcRQ3+h6vs/q3L8DZg +lN17Hs1z/JbnXRQKRCkCuL4eFVNrRi92tz1K0nJpF+qSk3LPg== X-Google-Smtp-Source: APXvYqwS+Ul0zwPhnKihf78ZgV2X/9/F/3YoqvxIMwTfEqqmdoLXc6VJBawp9dZoaQx67YKlwNyjcMA6TeUedLUV23Y= X-Received: by 2002:a92:6e09:: with SMTP id j9mr11029019ilc.178.1575628648668; Fri, 06 Dec 2019 02:37:28 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-Reply-To: From: Lorenzo Colitti Date: Fri, 6 Dec 2019 19:37:16 +0900 Message-ID: To: Philip Homburg Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000e764c9059906a1d8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 10:37:31 -0000 --000000000000e764c9059906a1d8 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 6, 2019 at 7:04 PM Philip Homburg wrote: > >I'm an operator who could not wait to implement that draft (and I'm > >aware of at least one other operator who might be interested). > >Maybe I'm not creative enough but all other options of incremental > >deployment of IPv6-only I've come up with are much more ugly > >(doubling the number of SSIDs/VLANs or having a portal when users have to > >request IPv4 so their MACs are whitelisted etc). > > Can you describe why offering both NAT64 and native IPv4 on the same lan > doesn't work? > It uses lots of IPv4 addresses. Additionally, many hosts prefer native IPv4 over IPv6+NAT64, so they will keep DHCP running even if they get IPv6 with NAT64. Even if the hosts changed this behaviour, hosts typically start IPv4 immediately when they connect. Because IPv6 provisioning is often slower than IPv4, the host will get an IPv4 address first. And once it gets an IPv4 address it generally doesn't want to release it later because doing so could disrupt application sockets. --000000000000e764c9059906a1d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 6, 2019 at 7:04 PM Philip Hom= burg <pch-v6ops-9@u-1.phic= oh.com> wrote:
>I'm an operator who could not wait= to implement that draft (and I'm
>aware of at least one other operator who might be interested).
>Maybe I'm not creative enough but all other options of incremental<= br> >deployment of IPv6-only I've come up with are much more ugly
>(doubling the number of SSIDs/VLANs or having a portal when users have = to
>request IPv4 so their MACs are whitelisted etc).

Can you describe why offering both NAT64 and native IPv4 on the same lan doesn't work?

It uses lots of IPv4 = addresses. Additionally, many hosts prefer native IPv4 over IPv6+NAT64, so = they will keep DHCP running even if they get IPv6 with NAT64. Even if the h= osts changed this behaviour, hosts typically start IPv4 immediately when th= ey connect. Because IPv6 provisioning is often slower than IPv4, the host w= ill get an IPv4 address first. And once it gets an IPv4 address it generall= y doesn't want to release it later because doing so could disrupt appli= cation sockets.
--000000000000e764c9059906a1d8-- From nobody Fri Dec 6 02:43:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0431202DD for ; Fri, 6 Dec 2019 02:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 dSnhecCwidTY for ; Fri, 6 Dec 2019 02:43:52 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12EF1200F5 for ; Fri, 6 Dec 2019 02:43:51 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id b15so5840445ila.7 for ; Fri, 06 Dec 2019 02:43:51 -0800 (PST) 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=uxSpAyEKZp/rC6Rc1wFTLeiSu3E3D9yZKnMHTqXrUGk=; b=WaWIpzFspvuuig8Jc+JSse8/Tg6ZGyGDBsV+aSMgag2EQMpo24yJ/rfCdW+sSU/rtD x2SWOI5HrWg5QeqSN9nMt6W1YmLEq6sM5q58rMDELVqam7HWoInQHLmziOXpIwUa2FyY rYZEjxfcljXzOeVSzZJIzkT2ghHTuaE5d41+rmOUdEfproPJIEWyWHdd+2Dj4Y3mY8Z/ 1miFqfyaq/RR6fCUVxfo0dnBtTnLLct2wlG5Nln7VqHNL8g6S/Bn3ADeO/UHnv5/XCvt Lb/bZu3sr3i5TJEeyzwAoKNpOBiNOtA48Dfvu+iW4VrtCrZtlOCSUzre7t0L1RMMI15E oAuA== 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=uxSpAyEKZp/rC6Rc1wFTLeiSu3E3D9yZKnMHTqXrUGk=; b=fzxF0UuCT4xoqpEk74O7FzbfAUIyqVidkM7pyFfZB1ZOjqLybQnxr4AV0wAlWY/yrC PO3Ch9rYolnXMdRLMMl6TUxXdoOB/46F9i7vTiEFQT++JXWXWIU8xRoBt9KLX8cvtLGm G16OgC+gP5Z6D4RT3ApgHHWxb0kxiLC95D3DVxb5CFXKaHP1f1NrMcEvrfU03uyRo+9K WImRdhWF6EkKdgnPRkfrLh+3g8KISIseECTCe3oXg566ULK/F/sreK5zbKad5IRvJ4Pv D+roYRWJ9T2xVmHzFK0Lex4ex4Imy/tft+5mQ9eR/j0EcyWgssBCpu3V/Ns4x/veL0Va QoeA== X-Gm-Message-State: APjAAAWEXI0v+Uz2S3m1ySaDerK5vjHxg+D91W/6wELehcix5/i00DJg AjzxNOjDkMZpF1xWNJa8bvzX/rYn1D58MaWQYjtNmQ== X-Google-Smtp-Source: APXvYqwmy5tkK7Lqq+mJ/N1+3A2tcAOOsQdJirWBLoYA5aEhFN8jKyib3+0ubyXXMz4TsDEv1xaOqX1asUMe5JUu+Rw= X-Received: by 2002:a92:ba93:: with SMTP id t19mr14344422ill.0.1575629030980; Fri, 06 Dec 2019 02:43:50 -0800 (PST) MIME-Version: 1.0 References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E5E90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E5E90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Fri, 6 Dec 2019 19:43:38 +0900 Message-ID: To: "" Cc: Jen Linkova , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b0e858059906b835" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 10:43:53 -0000 --000000000000b0e858059906b835 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 6, 2019 at 5:01 PM wrote: > *[Med] *Do you mean that clients that receive the signal to release IPv4 > configuration will make the users unhappy anyway because they will need t= o > wait for the pref64 to properly work? > > > > Well, that's the intent of the pref64 RA option. That allows the pref64 t= o > be communicated in the same packet as the rest of the configuration > parameters. > > [Med] If there is no delay then, the signals (pref64 presence, v6-only > presence) are redundant. No? > The pref64 option doesn't guarantee the absence of a delay. This DHCP option tell hosts: this network can provide IPv6-only service with NAT, and would prefer that hosts use it over IPv4. That gives the host a reason to wait before it configures IPv4, or not to configure IPv4 at all, because it knows that (unless there is an outage or misconfiguration), native IPv6 with NAT64 will arrive very soon. The pref64 option is there to ensure that NAT64 arrives as soon as possible and doesn't require roundtrips to the DNS forwarders (or even to the root and then to the IANA servers). > Note that IPv6 has built-in delays in the protocol itself (DAD for the > link-local address; various randomized delays) that make it very difficul= t > to get anything done before at least 1-2 seconds have passed. Hosts that > know that 70% of networks are IPv4-only will not want to wait 1-2 seconds > to connect to those networks. > > > > [Med] In that case, what is the benefit for the host to indicate its > ipv6-only mode support? > > > > The option improves the situation by allowing the host to wait for IPv6 > only if it is expected to exist. > > [Med] The host can =E2=80=9Cwait=E2=80=9D without requiring the option. T= he key point is > that an administrator sets =E2=80=9Cipv6-mode=E2=80=9D supported. > Which administrator? If you mean the host administrator: only very few hosts have administrators that understand networking. Most hosts don't. And it's silly to wait unconditionally if the host doesn't know if the network provides IPv6-only service. Almost all networks (except for cellular networks, which don't use DHCP) don't provide such a service today, and it doesn't make sense to wait unconditionally on all networks just because a very few networks support IPv6-only. --000000000000b0e858059906b835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 6, 2019 at 5:01 PM <mohamed.boucadair@orange.com&= gt; wrote:

[Med] Do you mean that clients that re= ceive the signal to release IPv4 configuration will make the users unhappy = anyway because they will need to wait for the pref64 to properly work?

=C2=A0

Well, that's the intent of the pref64 RA option.= That allows the pref64 to be communicated in the same packet as the rest o= f the configuration parameters.

[Med] If there is no del= ay then, the signals (pref64 presence, v6-only presence) are redundant. No?=


=
The pref64 option doesn't guarantee the absence of a delay. This D= HCP option tell hosts: this network can provide IPv6-only service with NAT,= and would prefer that hosts use it over IPv4. That gives the host a reason= to wait before it configures IPv4, or not to configure IPv4 at all, becaus= e it knows that (unless there is an outage or misconfiguration), native IPv= 6 with NAT64 will arrive very soon. The pref64 option is there to ensure th= at NAT64 arrives as soon as possible and doesn't require roundtrips to = the DNS forwarders (or even to the root and then to the IANA servers).=C2= =A0

Note that IPv6 has built-in del= ays in the protocol itself (DAD for the link-local address; various randomi= zed delays) that make it very difficult to get anything done before at least 1-2 seconds=C2=A0have passed. Hosts that know = that 70% of networks are IPv4-only will not want to wait 1-2 seconds to con= nect to those networks.

=C2=A0

[Med] In that case, what= is the benefit for the host to indicate its ipv6-only mode support?=

=C2=A0

The option improves the situation by allowing the ho= st to wait for IPv6 only if it is expected to exist.

[Med] The host can =E2= =80=9Cwait=E2=80=9D without requiring the option. The key point is that an = administrator sets =E2=80=9Cipv6-mode=E2=80=9D supported. =C2=A0=C2=A0


= Which administrator? If you mean the host administrator: only very few host= s have administrators that understand networking. Most hosts don't. And= it's silly to wait unconditionally if the host doesn't know if the= network provides IPv6-only service. Almost all networks (except for cellul= ar networks, which don't use DHCP) don't provide such a service tod= ay, and it doesn't make sense to wait unconditionally on all networks j= ust because a very few networks support IPv6-only.
--000000000000b0e858059906b835-- From nobody Fri Dec 6 04:25:52 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D251200FF; Fri, 6 Dec 2019 04:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si1yIvk3Ox5i; Fri, 6 Dec 2019 04:25:44 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E0212001E; Fri, 6 Dec 2019 04:25:44 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 47TsHp1Jn9z21pJ; Fri, 6 Dec 2019 13:25:42 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 47TsHp0T68zDq8c; Fri, 6 Dec 2019 13:25:42 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0468.000; Fri, 6 Dec 2019 13:25:41 +0100 From: To: Lorenzo Colitti CC: Jen Linkova , =?utf-8?B?QmrDuHJuIE1vcms=?= , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrCIE0EzcIgM90k+qjQhPGFF0raetA0RA Date: Fri, 6 Dec 2019 12:25:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E60F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E41EE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E429B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E4587@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330313E5E90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E60F8OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 12:25:46 -0000 --_000_787AE7BB302AE849A7480A190F8B9330313E60F8OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KRW52b3nDqSA6IHZlbmRyZWRp IDYgZMOpY2VtYnJlIDIwMTkgMTE6NDQNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0K Q2MgOiBKZW4gTGlua292YTsgQmrDuHJuIE1vcms7IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlz dDsgZHJhZnQtbGluay1kaGMtdjZvbmx5QGlldGYub3JnDQpPYmpldCA6IFJlOiBbZGhjd2ddIElQ djYtT25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbg0KDQpPbiBGcmksIERlYyA2LCAyMDE5IGF0 IDU6MDEgUE0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCltNZWRdIERvIHlvdSBtZWFuIHRoYXQgY2xpZW50 cyB0aGF0IHJlY2VpdmUgdGhlIHNpZ25hbCB0byByZWxlYXNlIElQdjQgY29uZmlndXJhdGlvbiB3 aWxsIG1ha2UgdGhlIHVzZXJzIHVuaGFwcHkgYW55d2F5IGJlY2F1c2UgdGhleSB3aWxsIG5lZWQg dG8gd2FpdCBmb3IgdGhlIHByZWY2NCB0byBwcm9wZXJseSB3b3JrPw0KDQpXZWxsLCB0aGF0J3Mg dGhlIGludGVudCBvZiB0aGUgcHJlZjY0IFJBIG9wdGlvbi4gVGhhdCBhbGxvd3MgdGhlIHByZWY2 NCB0byBiZSBjb21tdW5pY2F0ZWQgaW4gdGhlIHNhbWUgcGFja2V0IGFzIHRoZSByZXN0IG9mIHRo ZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuDQpbTWVkXSBJZiB0aGVyZSBpcyBubyBkZWxheSB0 aGVuLCB0aGUgc2lnbmFscyAocHJlZjY0IHByZXNlbmNlLCB2Ni1vbmx5IHByZXNlbmNlKSBhcmUg cmVkdW5kYW50LiBObz8NCg0KVGhlIHByZWY2NCBvcHRpb24gZG9lc24ndCBndWFyYW50ZWUgdGhl IGFic2VuY2Ugb2YgYSBkZWxheS4gVGhpcyBESENQIG9wdGlvbiB0ZWxsIGhvc3RzOiB0aGlzIG5l dHdvcmsgY2FuIHByb3ZpZGUgSVB2Ni1vbmx5IHNlcnZpY2Ugd2l0aCBOQVQsIGFuZCB3b3VsZCBw cmVmZXIgdGhhdCBob3N0cyB1c2UgaXQgb3ZlciBJUHY0Lg0KW01lZF0gQXNzdW1pbmcgdGhlIGhv c3QgaXMgbW9kaWZpZWQgdG8gYmVoYXZlIGluIHRoaXMgbW9kZS4NCg0KVGhhdCBnaXZlcyB0aGUg aG9zdCBhIHJlYXNvbiB0byB3YWl0IGJlZm9yZSBpdCBjb25maWd1cmVzIElQdjQsIG9yIG5vdCB0 byBjb25maWd1cmUgSVB2NCBhdCBhbGwsIGJlY2F1c2UgaXQga25vd3MgdGhhdCAodW5sZXNzIHRo ZXJlIGlzIGFuIG91dGFnZSBvciBtaXNjb25maWd1cmF0aW9uKSwgbmF0aXZlIElQdjYgd2l0aCBO QVQ2NCB3aWxsIGFycml2ZSB2ZXJ5IHNvb24uDQpbTWVkXSBTdGlsbCBpdCB3aWxsIHdhaXQgaW4g dGhhdCBjYXNlLg0KDQpUaGUgcHJlZjY0IG9wdGlvbiBpcyB0aGVyZSB0byBlbnN1cmUgdGhhdCBO QVQ2NCBhcnJpdmVzIGFzIHNvb24gYXMgcG9zc2libGUgYW5kIGRvZXNuJ3QgcmVxdWlyZSByb3Vu ZHRyaXBzIHRvIHRoZSBETlMgZm9yd2FyZGVycyAob3IgZXZlbiB0byB0aGUgcm9vdCBhbmQgdGhl biB0byB0aGUgSUFOQSBzZXJ2ZXJzKS4NCltNZWRdIFllcy4gTXkgcG9pbnQgaXMgdGhhdCB0aGlz IGluZm9ybWF0aW9uIGlzIGV4cGxpY2l0IGVub3VnaCB0aGF0IGEgTkFUNjQgc2VydmljZSBpcyBh dmFpbGFibGUgYW5kIHRoYXQgb25seSB0aGUgSVB2NiBwcmVmaXggc2hvdWxkIGJlIGNvbmZpZ3Vy ZWQuDQoNCkEgaG9zdCB0aGF0IGlzIG5vdCBzdXBwb3J0aW5nIHRoaXMgbW9kZSB3b27igJl0IHdh aXQgYW5kIHdpbGwgcmV0cmlldmUgYm90aCBpcHY0L0lQdjYgY29uZmlndXJhdGlvbiAoaWYgYXZh aWxhYmxlKS4NCg0KTm90ZSB0aGF0IElQdjYgaGFzIGJ1aWx0LWluIGRlbGF5cyBpbiB0aGUgcHJv dG9jb2wgaXRzZWxmIChEQUQgZm9yIHRoZSBsaW5rLWxvY2FsIGFkZHJlc3M7IHZhcmlvdXMgcmFu ZG9taXplZCBkZWxheXMpIHRoYXQgbWFrZSBpdCB2ZXJ5IGRpZmZpY3VsdCB0byBnZXQgYW55dGhp bmcgZG9uZSBiZWZvcmUgYXQgbGVhc3QgMS0yIHNlY29uZHMgaGF2ZSBwYXNzZWQuIEhvc3RzIHRo YXQga25vdyB0aGF0IDcwJSBvZiBuZXR3b3JrcyBhcmUgSVB2NC1vbmx5IHdpbGwgbm90IHdhbnQg dG8gd2FpdCAxLTIgc2Vjb25kcyB0byBjb25uZWN0IHRvIHRob3NlIG5ldHdvcmtzLg0KDQpbTWVk XSBJbiB0aGF0IGNhc2UsIHdoYXQgaXMgdGhlIGJlbmVmaXQgZm9yIHRoZSBob3N0IHRvIGluZGlj YXRlIGl0cyBpcHY2LW9ubHkgbW9kZSBzdXBwb3J0Pw0KDQpUaGUgb3B0aW9uIGltcHJvdmVzIHRo ZSBzaXR1YXRpb24gYnkgYWxsb3dpbmcgdGhlIGhvc3QgdG8gd2FpdCBmb3IgSVB2NiBvbmx5IGlm IGl0IGlzIGV4cGVjdGVkIHRvIGV4aXN0Lg0KW01lZF0gVGhlIGhvc3QgY2FuIOKAnHdhaXTigJ0g d2l0aG91dCByZXF1aXJpbmcgdGhlIG9wdGlvbi4gVGhlIGtleSBwb2ludCBpcyB0aGF0IGFuIGFk bWluaXN0cmF0b3Igc2V0cyDigJxpcHY2LW1vZGXigJ0gc3VwcG9ydGVkLg0KDQpXaGljaCBhZG1p bmlzdHJhdG9yPw0KW01lZF0gVGhlIG9uZSB5b3UgaGF2ZSBpbiB0aGUgZHJhZnQ6DQoNCiAgIEEg REhDUCBjbGllbnQgU0hPVUxEIGFsbG93IGEgZGV2aWNlIGFkbWluaXN0cmF0b3IgdG8gY29uZmln dXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5e DQogICBJUHY2LW9ubHkgcHJlZmVycmVkIG1vZGUgZWl0aGVyIGZvciBhIHNwZWNpZmljIGludGVy ZmFjZSAodG8gaW5kaWNhdGUNCiAgIHRoYXQgdGhlIGRldmljZSBpcyBJUHY2LW9ubHkgY2FwYWJs ZSBpZiBjb25uZWN0ZWQgdG8gYSBOQVQ2NCBuZXR3b3JrDQogICB2aWEgdGhhdCBpbnRlcmZhY2Up IG9yIGZvciBhbGwgaW50ZXJmYWNlcy4NCg0KUGVyaGFwcywgSSBtaXN1bmRlcnN0b29kIHRoZSBp bnRlbnQgb2YgdGhlIGRyYWZ0LiBJZiB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgbmV0d29yayBh ZG1pbmlzdHJhdG9yIHRoYXQgaXMgYWJsZSB0byB0b3VjaCB0aGF0IHBhcmFtZXRlciBvbiBob3N0 cyBvbiB0aGUgTEFOLCB0aGF0IGFkbWluaXN0cmF0b3IgY2FuIGFsc28gZGlzYWJsZSBkaGNwdjQg Zm9yIElQdjYtY2FwYWJsZSBkZXZpY2VzIChvbiBzcGVjaWZpYyBpbnRlcmZhY2VzL25ldHdvcmtz KS4gV2UgZG9u4oCZdCBoYXZlIGEgcHJvYmxlbSB0aGVtLg0KDQpPdGhlcndpc2UsIEkgZG9u4oCZ dCBzZWUgaG93IGEgZGV2aWNlIGNhbiBzZXQgYXV0b21hdGljYWxseSDigJxJUHY2LW9ubHkgcHJl ZmVycmVkIG1vZGXigJ0uIERvIHlvdT8NCg== --_000_787AE7BB302AE849A7480A190F8B9330313E60F8OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9y bWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDYgZMOpY2VtYnJl IDIwMTkgMTE6NDQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9P TE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEplbiBMaW5rb3ZhOyBCasO4cm4gTW9yazsgZGhjd2dA aWV0Zi5vcmc7IFY2IE9wcyBMaXN0OyBkcmFmdC1saW5rLWRoYy12Nm9ubHlAaWV0Zi5vcmc8YnI+ DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbZGhjd2ddIElQdjYtT25seSBQcmVmZXJyZWQgREhD UHY0IG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgNiwgMjAxOSBhdCA1OjAxIFBNICZsdDs8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W01lZF0NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij5EbyB5b3UgbWVhbiB0aGF0IGNsaWVudHMgdGhhdCByZWNlaXZlIHRoZSBzaWduYWwgdG8gcmVs ZWFzZSBJUHY0IGNvbmZpZ3VyYXRpb24gd2lsbCBtYWtlIHRoZSB1c2VycyB1bmhhcHB5IGFueXdh eSBiZWNhdXNlIHRoZXkgd2lsbCBuZWVkIHRvIHdhaXQgZm9yIHRoZSBwcmVmNjQNCiB0byBwcm9w ZXJseSB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PldlbGwsIHRoYXQncyB0aGUgaW50ZW50IG9mIHRoZSBwcmVmNjQgUkEgb3B0aW9uLiBUaGF0IGFs bG93cyB0aGUgcHJlZjY0IHRvIGJlIGNvbW11bmljYXRlZCBpbiB0aGUgc2FtZSBwYWNrZXQgYXMg dGhlIHJlc3Qgb2YgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltNZWRdIElmIHRoZXJlIGlzIG5vIGRlbGF5IHRoZW4sIHRoZSBzaWduYWxzIChwcmVmNjQg cHJlc2VuY2UsIHY2LW9ubHkgcHJlc2VuY2UpIGFyZSByZWR1bmRhbnQuDQogTm8/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBy ZWY2NCBvcHRpb24gZG9lc24ndCBndWFyYW50ZWUgdGhlIGFic2VuY2Ugb2YgYSBkZWxheS4gVGhp cyBESENQIG9wdGlvbiB0ZWxsIGhvc3RzOiB0aGlzIG5ldHdvcmsgY2FuIHByb3ZpZGUgSVB2Ni1v bmx5IHNlcnZpY2Ugd2l0aCBOQVQsIGFuZCB3b3VsZCBwcmVmZXIgdGhhdCBob3N0cyB1c2UgaXQg b3ZlciBJUHY0Lg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5bTWVkXSBBc3N1bWluZyB0aGUgaG9zdCBpcyBtb2RpZmllZCB0byBiZWhhdmUgaW4g dGhpcyBtb2RlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYXQgZ2l2ZXMgdGhlIGhvc3QgYSByZWFzb24gdG8gd2FpdCBiZWZvcmUgaXQgY29u ZmlndXJlcyBJUHY0LCBvciBub3QgdG8gY29uZmlndXJlIElQdjQgYXQgYWxsLCBiZWNhdXNlIGl0 IGtub3dzIHRoYXQgKHVubGVzcyB0aGVyZSBpcyBhbiBvdXRhZ2Ugb3IgbWlzY29uZmlndXJhdGlv biksIG5hdGl2ZSBJUHY2IHdpdGggTkFUNjQgd2lsbCBhcnJpdmUgdmVyeSBzb29uLjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRd IFN0aWxsIGl0IHdpbGwgd2FpdCBpbiB0aGF0IGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcmVmNjQgb3B0aW9uIGlzIHRoZXJlIHRv IGVuc3VyZSB0aGF0IE5BVDY0IGFycml2ZXMgYXMgc29vbiBhcyBwb3NzaWJsZSBhbmQgZG9lc24n dCByZXF1aXJlIHJvdW5kdHJpcHMgdG8gdGhlIEROUyBmb3J3YXJkZXJzIChvciBldmVuIHRvIHRo ZSByb290IGFuZCB0aGVuIHRvIHRoZSBJQU5BIHNlcnZlcnMpLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWVkXSBZZXMuIE15IHBvaW50IGlzIHRoYXQgdGhpcyBpbmZvcm1hdGlvbiBp cyBleHBsaWNpdCBlbm91Z2ggdGhhdCBhIE5BVDY0IHNlcnZpY2UgaXMgYXZhaWxhYmxlIGFuZCB0 aGF0IG9ubHkgdGhlIElQdjYgcHJlZml4IHNob3VsZCBiZSBjb25maWd1cmVkLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5BIGhvc3QgdGhh dCBpcyBub3Qgc3VwcG9ydGluZyB0aGlzIG1vZGUgd29u4oCZdCB3YWl0IGFuZCB3aWxsIHJldHJp ZXZlIGJvdGggaXB2NC9JUHY2IGNvbmZpZ3VyYXRpb24gKGlmIGF2YWlsYWJsZSkuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdGUgdGhhdCBJ UHY2IGhhcyBidWlsdC1pbiBkZWxheXMgaW4gdGhlIHByb3RvY29sIGl0c2VsZiAoREFEIGZvciB0 aGUgbGluay1sb2NhbCBhZGRyZXNzOyB2YXJpb3VzIHJhbmRvbWl6ZWQgZGVsYXlzKSB0aGF0IG1h a2UgaXQgdmVyeSBkaWZmaWN1bHQgdG8gZ2V0IGFueXRoaW5nDQogZG9uZSBiZWZvcmUgYXQgbGVh c3QgMS0yIHNlY29uZHMmbmJzcDtoYXZlIHBhc3NlZC4gPC9zcGFuPkhvc3RzIHRoYXQga25vdyB0 aGF0IDcwJSBvZiBuZXR3b3JrcyBhcmUgSVB2NC1vbmx5IHdpbGwgbm90IHdhbnQgdG8gd2FpdCAx LTIgc2Vjb25kcyB0byBjb25uZWN0IHRvIHRob3NlIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEluIHRoYXQgY2FzZSwg d2hhdCBpcyB0aGUgYmVuZWZpdCBmb3IgdGhlIGhvc3QgdG8gaW5kaWNhdGUgaXRzIGlwdjYtb25s eSBtb2RlIHN1cHBvcnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIG9wdGlvbiBpbXByb3ZlcyB0aGUgc2l0dWF0aW9uIGJ5IGFsbG93aW5nIHRoZSBo b3N0IHRvIHdhaXQgZm9yIElQdjYgb25seSBpZiBpdCBpcyBleHBlY3RlZCB0byBleGlzdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltNZWRdIFRoZSBob3N0IGNhbiDigJx3YWl04oCdIHdpdGhvdXQgcmVx dWlyaW5nIHRoZSBvcHRpb24uIFRoZSBrZXkgcG9pbnQgaXMgdGhhdCBhbiBhZG1pbmlzdHJhdG9y DQogc2V0cyDigJxpcHY2LW1vZGXigJ0gc3VwcG9ydGVkLiAmbmJzcDsmbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGljaCBh ZG1pbmlzdHJhdG9yPzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W01lZF0gVGhlIG9uZSB5b3UgaGF2ZSBpbiB0aGUgZHJhZnQ6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQSBESENQIGNsaWVu dCBTSE9VTEQgYWxsb3cgYSBkZXZpY2UgYWRtaW5pc3RyYXRvciB0byBjb25maWd1cmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwO0lQdjYtb25seSBwcmVmZXJyZWQgbW9kZSBlaXRoZXIgZm9yIGEgc3BlY2lmaWMg aW50ZXJmYWNlICh0byBpbmRpY2F0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIGRl dmljZSBpcyBJUHY2LW9ubHkgY2FwYWJsZSBpZiBjb25uZWN0ZWQgdG8gYSBOQVQ2NCBuZXR3b3Jr PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdmlhIHRoYXQgaW50ZXJmYWNlKSBvciBmb3IgYWxsIGlu dGVyZmFjZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5QZXJoYXBzLCBJIG1pc3VuZGVyc3Rvb2QgdGhlIGludGVudCBvZiB0aGUgZHJhZnQu IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IgdGhhdCBp cyBhYmxlIHRvIHRvdWNoIHRoYXQgcGFyYW1ldGVyIG9uIGhvc3RzIG9uIHRoZQ0KIExBTiwgdGhh dCBhZG1pbmlzdHJhdG9yIGNhbiBhbHNvIGRpc2FibGUgZGhjcHY0IGZvciBJUHY2LWNhcGFibGUg ZGV2aWNlcyAob24gc3BlY2lmaWMgaW50ZXJmYWNlcy9uZXR3b3JrcykuIFdlIGRvbuKAmXQgaGF2 ZSBhIHByb2JsZW0gdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk90aGVyd2lzZSwgSSBkb27igJl0IHNlZSBob3cgYSBkZXZpY2UgY2Fu IHNldCBhdXRvbWF0aWNhbGx5IOKAnElQdjYtb25seSBwcmVmZXJyZWQgbW9kZeKAnS4gRG8geW91 PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B9330313E60F8OPEXCAUBMA2corp_-- From nobody Fri Dec 6 04:39:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB8C1200B6 for ; Fri, 6 Dec 2019 04:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiDgkU-6D_pB for ; Fri, 6 Dec 2019 04:39:39 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABA812001E for ; Fri, 6 Dec 2019 04:39:38 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D2458411B6 for ; Fri, 6 Dec 2019 13:39:36 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C50A54105A; Fri, 6 Dec 2019 13:39:36 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id B50BA692D1; Fri, 6 Dec 2019 13:39:36 +0100 (CET) Date: Fri, 6 Dec 2019 13:39:36 +0100 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org Message-ID: <20191206123936.GP72330@Space.Net> References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 12:39:41 -0000 Hi, On Fri, Dec 06, 2019 at 11:04:07AM +0100, Philip Homburg wrote: > >I'm an operator who could not wait to implement that draft (and I'm > >aware of at least one other operator who might be interested). > >Maybe I'm not creative enough but all other options of incremental > >deployment of IPv6-only I've come up with are much more ugly > >(doubling the number of SSIDs/VLANs or having a portal when users have to > >request IPv4 so their MACs are whitelisted etc). > > Can you describe why offering both NAT64 and native IPv4 on the same lan > doesn't work? "number of IPv4 addresses in the pool" comes to mind. Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large enough subnet to cover 100% of all expected hosts if 20% will do? IPv4 seems to be somewhat in short supply these days. 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 Dec 6 06:10:33 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA99F12080A for ; Fri, 6 Dec 2019 06:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 ClIaoMsTruTc for ; Fri, 6 Dec 2019 06:10:30 -0800 (PST) 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 454C7120041 for ; Fri, 6 Dec 2019 06:10:30 -0800 (PST) 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 m1idEJQ-0000KPC; Fri, 6 Dec 2019 15:10:28 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <20191206123936.GP72330@Space.Net> In-reply-to: Your message of "Fri, 6 Dec 2019 13:39:36 +0100 ." <20191206123936.GP72330@Space.Net> Date: Fri, 06 Dec 2019 15:10:23 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:10:32 -0000 >"number of IPv4 addresses in the pool" comes to mind. > >Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large >enough subnet to cover 100% of all expected hosts if 20% will do? > >IPv4 seems to be somewhat in short supply these days. With a few exceptions, just about any DHCP pool I come across these days is using RFC 1918. Are you running out of RFC 1918 addresses in your pool? Or is the setup that you give publicly routable IPv4 addresses to all dual stack hosts and want to only put hosts that support NAT64 behind NAT? In that case, what's the rational for providing dual stack hosts with public IPv4 addresses? From nobody Fri Dec 6 06:31:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6F120041 for ; Fri, 6 Dec 2019 06:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CinWJngUZRLj for ; Fri, 6 Dec 2019 06:31:01 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C0812080A for ; Fri, 6 Dec 2019 06:31:01 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id o11so2816263pjp.9 for ; Fri, 06 Dec 2019 06:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=85Ebu1Tg/fb8iG/vBwSdd2Xs/BHjux9+FU1BFC3GSC0=; b=qGckrCLrr7QBHYF40OzJ3gTLw5ShuCr+gwdnj/mk2jJ2KnMBbe5D4mlH1vuSWu2y0T jHaj5DtAh2gGL8Ad+Ft0hPw9zBZdGmVIiYDAw3DVsMm1WlbGme6SyxfMgOOre5Ux+8S6 9kQb2kjW7AAemQCwfJTmadjcLx2SSKE8PUP+0m5+H7bcwmq80JjFUAfm1VHjgN6joLeJ OWirXPWhNf9sdjKJZgKfSa4403MFBQBm6i9OOST2qHy3s/smTjGlPwFXnDXniKDZFJBm HV3tI4uvw0iM3uxbtQb9dRdFyWkxa8aP+7GA84fXrKwNr+XWmzVJVHPTtLuoZrAj8RG6 P4UA== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=85Ebu1Tg/fb8iG/vBwSdd2Xs/BHjux9+FU1BFC3GSC0=; b=Kzi4VYAFHO4gmyJYdzAI+aSTbvzUm/enk63rKMSRCpzmj0VKVxmZezBQxf7foofLca i5Z+mt+s7KRlo/4+ClHn50x0zlb6hURVyEDrLzuYCLvTre87rRNjoX8gH2YjXncmorRI pGbFSxc9qAVflKEHiQIZ2ImLiujWLXA3nrWArhh15hxNVbo46gsZNlJSjpTRuAN0y87N KYYoHhHMX4dAl11B96yq1tK+5ecQrw/bXIouVR8ARF6m851/DJShUQ+Cw7oxhiD5qwfD RaM8WodUqjhKAE7rqlqOxWkHCS7qujZxaFWYzVTOZrU6VqgAWr3XZiOWaWyFTCI4TllB pMJg== X-Gm-Message-State: APjAAAViOADha1SKEnHYyQo4TtYBv5Umthl1ZzgXG3ozQSzZ1ccOe1lA wEVQbdMluFlEwp626qAcVJqKn2o78V6r4Q== X-Google-Smtp-Source: APXvYqxKfJFg7vcfuT1sIkkBSuwhjfrlVFvz1Yw2BK7legYQErr2KMqQKyez2GdbaSB0n3Vh7lHcTw== X-Received: by 2002:a17:902:b484:: with SMTP id y4mr15437136plr.166.1575642660259; Fri, 06 Dec 2019 06:31:00 -0800 (PST) Received: from [10.20.3.126] (ip-64-134-236-149.public.wayport.net. [64.134.236.149]) by smtp.gmail.com with ESMTPSA id e11sm3477097pjj.26.2019.12.06.06.30.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Dec 2019 06:30:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 6 Dec 2019 06:30:56 -0800 Message-Id: References: Cc: v6ops@ietf.org In-Reply-To: To: Philip Homburg X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:31:04 -0000 I really feel like there is some point-missing going on here. It is trivial t= o make this feature only activate for clients that support it. If that is do= ne, then there is no reason to assign an address at all. The offer doesn=E2=80= =99t even need to include that option. So any discussion of what address to s= end is irrelevant and unnecessary.=20 > On Dec 6, 2019, at 06:10, Philip Homburg wrot= e: >=20 > =EF=BB=BF >>=20 >> "number of IPv4 addresses in the pool" comes to mind. >>=20 >> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large= >> enough subnet to cover 100% of all expected hosts if 20% will do? >>=20 >> IPv4 seems to be somewhat in short supply these days. >=20 > With a few exceptions, just about any DHCP pool I come across these=20 > days is using RFC 1918. >=20 > Are you running out of RFC 1918 addresses in your pool? Or is the setup > that you give publicly routable IPv4 addresses to all dual stack hosts > and want to only put hosts that support NAT64 behind NAT? >=20 > In that case, what's the rational for providing dual stack hosts with publ= ic > IPv4 addresses? >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 6 06:38:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3347120041 for ; Fri, 6 Dec 2019 06:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDsTYZCXLEtc for ; Fri, 6 Dec 2019 06:38:33 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BBB120020 for ; Fri, 6 Dec 2019 06:38:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 81841411B6 for ; Fri, 6 Dec 2019 15:38:31 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7374E4105A; Fri, 6 Dec 2019 15:38:31 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 64E4069729; Fri, 6 Dec 2019 15:38:31 +0100 (CET) Date: Fri, 6 Dec 2019 15:38:31 +0100 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org, Gert Doering Message-ID: <20191206143831.GQ72330@Space.Net> References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <20191206123936.GP72330@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GW2aGKJs6Oq6raWk" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:38:36 -0000 --GW2aGKJs6Oq6raWk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 06, 2019 at 03:10:23PM +0100, Philip Homburg wrote: > >"number of IPv4 addresses in the pool" comes to mind. > > > >Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large > >enough subnet to cover 100% of all expected hosts if 20% will do? > > > >IPv4 seems to be somewhat in short supply these days. >=20 > With a few exceptions, just about any DHCP pool I come across these=20 > days is using RFC 1918. What a horrible way! Forcing your users behind a NAT! > Are you running out of RFC 1918 addresses in your pool? Or is the setup > that you give publicly routable IPv4 addresses to all dual stack hosts > and want to only put hosts that support NAT64 behind NAT? >=20 > In that case, what's the rational for providing dual stack hosts with pub= lic > IPv4 addresses? What's the rationale for forcing NAT44 on your users? (Speaking of a certain dual-stack ssid, why are we offering public v4=20 there?) 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 --GW2aGKJs6Oq6raWk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl3qZ+QACgkQ31bAZeTO f8VnHQ//VdLDOA7PIMWuEhoYxi/mrpQuV83HCoGRAbZCc+ShrjSiDtmd1dlEd9Ck kEQ30i/RfBUysFJk5dKpDr40n09/7Pnh63BL56xUDXWGmstUeREVrbNDQ8nPmGQT ZJRjRouSCIwV19APhom5+H2WAWPxY9vAr2vPW0WAw87Uu1446hIdn2W0xePyE5zR cdapAJwHXQmOgjpTDBGsEYro4RUqW5HVEINdmSL74yB9SK9ROcdsHYIiLNr48eJG SMQHGJ5BpOBZVsGyVaHyCUQTjJ4Qw5T/Q2t8hdP4sVTyuH4o2QWp1qVgg41bO7ET K5YmSNcebGb+fNRJ/l1wy0MVkXQEbw+tzZkxcG3moF7uYcXOpaRz0UKr38TKuQWi 2zrX+mAKchKNJ8tjZ6A28jwxQUCGIaAEG1veoI5cZB9lFUOiMQUJvP+H9REib71K /jnHSEduCdvWCkMRyVvRmttPuvAXdNUg+yNvoYQBRcjy6BSpUyLoiKUp6s6k84X4 8T99S6tYmSUQDIYnChZ2pMhP2AuGhRxGoaDG9VVKi3rGyeqQHnPbvjy/KALily1i m7sd8HCdsTEUxkArUSwXDQHjDfa2zAKgQvANQvpBiRpmmcocIHSk+mNPfhXKF8Q9 5OLYWWYLwCC4IP2qK6r0Y5eoKljm5nVXoA3FoIWy86Y1RIkhtZU= =Vbfo -----END PGP SIGNATURE----- --GW2aGKJs6Oq6raWk-- From nobody Fri Dec 6 06:45:43 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A36C1200B1; Fri, 6 Dec 2019 06:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=HcLBn+KW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v2P3EzUc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYZjiN_emBPN; Fri, 6 Dec 2019 06:45:32 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40E1120020; Fri, 6 Dec 2019 06:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4524; q=dns/txt; s=iport; t=1575643532; x=1576853132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8aArEA7MZ4J15OaUyn0Mo7W73GAVKkr4a5o1TllR7aQ=; b=HcLBn+KWyhnTXCjSr4UaVE5kRyqxdF3VlrYD9U3IZ1vPukWPUCbTs0Qe XOxRgKl/RTMqlA03sh0PKFv04FWiv0WCT/eHqycZPYoRZVYtD5+PhqAEy 5WBRDU5QFGfFKiz54A8xYNttjXMIv/TufF/tvWIK1F6XHcem2zxf3LmE+ s=; IronPort-PHdr: =?us-ascii?q?9a23=3A5ZQ9qxAPbhWj9OETNNLhUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFP8KOzCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAACXaOpd/51dJa1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoHAQELAYFKUAVsWCAECyoKhCGDRgOEWoYkgl+YBIEugSQDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEQAIXgX4kNAkOAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQE?= =?us-ascii?q?CAQEBEBERDAEBLAsBBAcEAgEIDgMEAQEBAgImAgICJQsVCAgCBAENBQgagwG?= =?us-ascii?q?CRgMOIAECDKIMAoE4iGB1gTKCfgEBBYE1AYNaGIIXAwaBDigBjBYaggCBWIJ?= =?us-ascii?q?MPoJkAQGBTQIWgw4ygiyNMIJxnT1wCoIulXWaJoxagXCaIwIEAgQFAg4BAQW?= =?us-ascii?q?BUjmBWHAVO4JsUBEUjGaDc4UUhT90gSiNfwEGHwSBBwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208";a="396523510" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 14:45:30 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6EjU8x015479 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 14:45:30 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 08:45:29 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 08:45:29 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 09:45:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=njEGjSPdn3Juw8So6Lx2hwt2j+Z+LxT5NRjCS3fOMi9LTpHOdujuZOFej8N+NbhA0NZ5YbmKyJkXk8D3NiLxoKVi7Gf7wxNZe6dBNB+nRvDizrhfQwMJAI4kzb5tG1lRFhhLpP+hm7YSRenRvyWVpMMMS0FaBArstSRt+2LG+Mv4gnl3MEWShg9EacCcZMJVEgHoTRMAvMKwl65ivTg+oDPTkIpzIijIDaDZmXe/rpYfLIT+ZHVrz8hAj8ySjLAZLmWLo2vGZ8j79gTUsyTeSq7HbFHNtTWOa3i4p9YfW+9mVxxkzDupnEPGrbZ0MsSFPjMBhXqo5Zy5KByFoXfdXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8aArEA7MZ4J15OaUyn0Mo7W73GAVKkr4a5o1TllR7aQ=; b=gfGxt6Vo2LY2y48wpIsLF7sLNF2BMU9au40pNyuDEa2WEr8dZ9fqjJ+IKRDDGnJi9N14V63y3+Fch07lybeAAo7pksFgq8M41+mhLVqc2pM0A3mmZgFdvviq1ieuHDxg+Nea/BRJ5bP2WKKLq1amt4BFRk5kLua+xkgWZVcvF+WhofucBlVCwk9Xyw+w3PIO/iD3UoGP3N5gU16aRdDfC9/od0cCvcnB6txym1O5Tj3ockDjbWQpzEMZqvLjE7iBQCQvUhAay2DdLBFsNhY0cWFraOPPlVlU6hAU5vnVR91ZEDThtqQNPgsHGrse/NMD0+c7qdBoI5ReXBodWaBGrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8aArEA7MZ4J15OaUyn0Mo7W73GAVKkr4a5o1TllR7aQ=; b=v2P3EzUc0/d93j/efSj+KKr/qCMBrk+jEk7Wzag5gmIeAnwjyDuUpVfOeGR5EPlXS17OGUDFRgUiBFsgo3wFFefQEvXGFoTwc/KLyAsXtwD0HTQllQzgWHkOtMsAIw31TxW4yQhrm3TyCbH30nzNxn7f+EvnjeQtrnv2L6cNoTA= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4009.namprd11.prod.outlook.com (20.176.125.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.13; Fri, 6 Dec 2019 14:45:28 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 14:45:28 +0000 From: "Bernie Volz (volz)" To: Ted Lemon , Philip Homburg CC: "v6ops@ietf.org" , "dhcwg@ietf.org" Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrEHbgQve9DKh2EKQEqgwr7Y10qetK3KQ Date: Fri, 6 Dec 2019 14:45:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dde8f7d2-5037-41a4-f22e-08d77a5aeffb x-ms-traffictypediagnostic: DM6PR11MB4009: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(13464003)(189003)(4326008)(76176011)(6506007)(478600001)(55016002)(7696005)(99286004)(53546011)(26005)(966005)(66446008)(74316002)(33656002)(305945005)(316002)(186003)(8676002)(54906003)(81156014)(8936002)(86362001)(66946007)(2906002)(71190400001)(110136005)(64756008)(66556008)(66476007)(71200400001)(5660300002)(9686003)(52536014)(102836004)(229853002)(81166006)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4009; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +faS6HXdgA6MQrpYjqASoes3lEKX89u2BXGl9vUqtR+uBcfXMK/5TlHUfSzmT8VbJyPU5wgXUb9UrdegvF4dl8yacCQxVPdvpNh84+RCKMuw29NyGcXGzuEN2EzWkdraQPd+4odaIu9hIxyvcZqGtbmUH3b770ZyEz9zDK7cj9K7+YCpEADe+GkcEnGm1ykKfCY9BIDi/rcfOKBTpPvudfZYDs58DN9xDXJqe31xhTNENRgT+PF+hDoBTO4lOTSb53CcNG7hjY2xsqiyq4C0DlwUUzN1RL1b9QFFSOpYPQAOypOgVPvD79jW7c6KqAx4y21gK9Ivjqm01SRicAwUjUl9oU/Xx+nBQ/HpvVDL3pfA1zBwv2sgVJc1bXgpz9WYpcAmJc97SJud2bFGsceQe1JfQFjAaR5LnYQUooFddepyA2n5XD1zFf2kVIMy8kIM5tCJO1OWUDu+Hczc6XQdmhjRlITa281oY90/w/gaRlkwbikZahq5qNqgJoiFaRMapRcnm2HBTDNhx0yVBbZCzejji1LfTK7+MMAKRbhmLNE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dde8f7d2-5037-41a4-f22e-08d77a5aeffb X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 14:45:28.7896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ORxBCL1YBNnHuaLvUTH13crDWiguwI4+8I5WM0E8UlXiK72BCZF3WMowgShkSpie X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4009 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:45:35 -0000 RXZlbiBpZiBhbiAiYXNzaWduZWQiIGFkZHJlc3MgaXMgc2VudCAod2hpY2ggcmVxdWlyZXMgZmV3 ZXIgY2hhbmdlcyBvbiB0aGUgREhDUCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24pLCBpdCBzaG91bGQg b25seSBiZSAiYXNzb2NpYXRlZCIgd2l0aCB0aGF0IGNsaWVudCBmb3IgYSB2ZXJ5IHNob3J0IGR1 cmF0aW9uICh0aGUgc2VydmVyIEkgd29yayBvbiBsaW1pdHMgaXQgdG8gMiBtaW51dGVzIGJ5IGRl ZmF1bHQgYW5kIHRoaXMgaXMgbm90IHNhdmVkIHRvIHBlcnNpc3RlbnQgc3RvcmFnZSkuIEEgREhD UEFDSyBpcyB3aGF0IGNvbmZpcm1zIHRoZSBsZWFzZSBmb3IgdGhlIHJldHVybmVkIGxlYXNlLXRp bWUgYW5kIHRoaXMgaXMgbmV2ZXIgc2VudCAoYXMgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIGEg REhDUFJFUVVFU1QgcGVyIHRoZSBkcmFmdCkuDQoNCkV4aXN0aW5nIHNlcnZlcnMgY2FuIGRlcGxv eSB0aGlzIHdpdGhvdXQgQU5ZIGNoYW5nZXMgKHByb3ZpZGVkIHlvdSBoYXZlIGEgbWVhbnMgdG8g Y29uZmlndXJlIHRoZSBzZXJ2ZXIgd2l0aCB3aGF0ZXZlciBvcHRpb24gbnVtYmVyIGlzIGZpbmFs bHkgYXNzaWduZWQpLg0KDQpQZXJzb25hbGx5LCBJIHdvdWxkIE5PVCByZWNvbW1lbmQgYnJlYWtp bmcgdGhlIHNlbWFudGljcyBvZiBhIERIQ1BPRkZFUiBhbmQgYWx3YXlzIGluY2x1ZGUgYW4gYWRk cmVzcyBiZWNhdXNlIHlvdSBuZXZlciBrbm93IGhvdyBpbnRlcm1lZGlhdGUgZGV2aWNlcyB0aGF0 IG1heSBiZSAic25vb3BpbmciIHRoaXMgdHJhZmZpYyB3aWxsIGhhbmRsZSB0aGlzOyBmb3IgZXhh bXBsZSwgdGhlIGludGVybWVkaWF0ZSBkZXZpY2UgbWlnaHQgZHJvcCB3aGF0IGl0IGZlZWxzIGlz IGFuIGludmFsaWQgcGFja2V0Lg0KDQpPbmUgY2hhbmdlIHRvIHRoZSBzZXJ2ZXIgbWF5IGJlIHRv IHNpbXBseSBub3QgZXZlbiB0ZW1wb3JhcmlseSBhc3NvY2lhdGUgdGhlICdhc3NpZ25lZCcgYWRk cmVzcyB3aXRoIHRoZSBjbGllbnQgKHNpbmNlIHRoZSBjbGllbnQgaXMgbm90IGV4cGVjdGVkIHRv IHNlbmQgYSBESENQUkVRVUVTVCkuIEJ1dCwgYWdhaW4sIEkgZG91YnQgdGhpcyB3b3VsZCBiZSBu ZWNlc3NhcnkuDQoNCkV2ZW4gaW4gY2FzZXMgd2hlcmUgdGhlcmUgYXJlIG1pbmltYWwgYWRkcmVz c2VzIGF2YWlsYWJsZSB3aXRoIGEgbG90IG9mIGNsaWVudHMgY29taW5nIG9ubGluZSBhdCBvbmNl LCB0aGUgREhDUCBzZXJ2ZXIgd291bGQgZHJvcCBESENQRElTQ09WRVJzIHRoYXQgaXQgaGFzIG5v IGF2YWlsYWJsZSBsZWFzZSBmb3IuIFRodXMsIHRoZSBjbGllbnQgd2lsbCBqdXN0IHJldHJ5IGZv ciBhIGJpdCB1bnRpbCBhbiBhZGRyZXNzIGJlY29tZXMgYXZhaWxhYmxlLiBCdXQgb3RoZXIgdGhh biBnZW5lcmF0aW5nIHRoZSBleGNlc3MgdHJhZmZpYywgdGhlIGVuZCByZXN1bHQgaXMgdGhlIHNh bWUgZXZlbnR1YWxseSAtIHRoZSBjbGllbnQgd2lsbCBzdG9wIERIQ1AuDQoNClRoaXMgaXMgb25l IG5pY2UgYXNwZWN0IG9mIHRoaXMgZGVzaWduIC0gdGhlcmUgYXJlIG1pbmltYWwgY2hhbmdlcyBu ZWVkZWQgdG8gZGVwbG95IGl0IGF0IHNlcnZlcnMgKGFuZCBpbiBmYWN0LCBtb3N0IHNlcnZlcnMg bWF5IG5lZWQgbm8gY2hhbmdlcykuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IFRlZCBMZW1vbg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciA2LCAyMDE5IDk6MzEgQU0NClRvOiBQ aGlsaXAgSG9tYnVyZyA8cGNoLXY2b3BzLTlAdS0xLnBoaWNvaC5jb20+DQpDYzogdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYtT25seSBQcmVmZXJyZWQgREhDUHY0IG9w dGlvbg0KDQpJIHJlYWxseSBmZWVsIGxpa2UgdGhlcmUgaXMgc29tZSBwb2ludC1taXNzaW5nIGdv aW5nIG9uIGhlcmUuIEl0IGlzIHRyaXZpYWwgdG8gbWFrZSB0aGlzIGZlYXR1cmUgb25seSBhY3Rp dmF0ZSBmb3IgY2xpZW50cyB0aGF0IHN1cHBvcnQgaXQuIElmIHRoYXQgaXMgZG9uZSwgdGhlbiB0 aGVyZSBpcyBubyByZWFzb24gdG8gYXNzaWduIGFuIGFkZHJlc3MgYXQgYWxsLiBUaGUgb2ZmZXIg ZG9lc27igJl0IGV2ZW4gbmVlZCB0byBpbmNsdWRlIHRoYXQgb3B0aW9uLiBTbyBhbnkgZGlzY3Vz c2lvbiBvZiB3aGF0IGFkZHJlc3MgdG8gc2VuZCBpcyBpcnJlbGV2YW50IGFuZCB1bm5lY2Vzc2Fy eS4gDQoNCj4gT24gRGVjIDYsIDIwMTksIGF0IDA2OjEwLCBQaGlsaXAgSG9tYnVyZyA8cGNoLXY2 b3BzLTlAdS0xLnBoaWNvaC5jb20+IHdyb3RlOg0KPiANCj4g77u/DQo+PiANCj4+ICJudW1iZXIg b2YgSVB2NCBhZGRyZXNzZXMgaW4gdGhlIHBvb2wiIGNvbWVzIHRvIG1pbmQuDQo+PiANCj4+IExp a2UsIDgwJSBvZiBhbGwgaG9zdHMgYXJlIGZpbmUgd2l0aCBJUHY2K05BVDY0LCBzbyB3aHkgcHJv dmlzaW9uIGEgDQo+PiBsYXJnZSBlbm91Z2ggc3VibmV0IHRvIGNvdmVyIDEwMCUgb2YgYWxsIGV4 cGVjdGVkIGhvc3RzIGlmIDIwJSB3aWxsIGRvPw0KPj4gDQo+PiBJUHY0IHNlZW1zIHRvIGJlIHNv bWV3aGF0IGluIHNob3J0IHN1cHBseSB0aGVzZSBkYXlzLg0KPiANCj4gV2l0aCBhIGZldyBleGNl cHRpb25zLCBqdXN0IGFib3V0IGFueSBESENQIHBvb2wgSSBjb21lIGFjcm9zcyB0aGVzZSANCj4g ZGF5cyBpcyB1c2luZyBSRkMgMTkxOC4NCj4gDQo+IEFyZSB5b3UgcnVubmluZyBvdXQgb2YgUkZD IDE5MTggYWRkcmVzc2VzIGluIHlvdXIgcG9vbD8gT3IgaXMgdGhlIA0KPiBzZXR1cCB0aGF0IHlv dSBnaXZlIHB1YmxpY2x5IHJvdXRhYmxlIElQdjQgYWRkcmVzc2VzIHRvIGFsbCBkdWFsIHN0YWNr IA0KPiBob3N0cyBhbmQgd2FudCB0byBvbmx5IHB1dCBob3N0cyB0aGF0IHN1cHBvcnQgTkFUNjQg YmVoaW5kIE5BVD8NCj4gDQo+IEluIHRoYXQgY2FzZSwgd2hhdCdzIHRoZSByYXRpb25hbCBmb3Ig cHJvdmlkaW5nIGR1YWwgc3RhY2sgaG9zdHMgd2l0aCANCj4gcHVibGljDQo+IElQdjQgYWRkcmVz c2VzPw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3Bz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Fri Dec 6 06:51:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E255F1200C5; Fri, 6 Dec 2019 06:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JbWFq7AN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wEfhwemo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWL6toiiOd-5; Fri, 6 Dec 2019 06:51:28 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DE1120020; Fri, 6 Dec 2019 06:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2336; q=dns/txt; s=iport; t=1575643888; x=1576853488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zD755vKnWIEIYEX/P5/SOZqUyb949PFpcQ+M2DGS9Xs=; b=JbWFq7AN9D3Mr2VNbmLVMWVDQ9jfIsI279WYN48EW7efTuammaHgQENh cIh+wWBgioyOLR3G1FL/GIQxEgxrhnmS6MwcurCzm61BwjfCsYBr/Krlr puOq1+EEXmcpMl9zIq8Z9GMZLoX806lgjR6akTKdbYj1YZFtSAfNw/Y4V U=; IronPort-PHdr: =?us-ascii?q?9a23=3AkJWexhYrxyH5U34M1dAUgtf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuMvnufQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAACWaepd/5xdJa1kGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagYBAQELAYFKUAVsWCAECyoKhCGDRgOEWoYjgl+YBIE?= =?us-ascii?q?ugSQDVAkBAQEMAQEYCwoCAQGEQAIXgX4kNAkOAgMNAQEEAQEBAgEFBG2FNwy?= =?us-ascii?q?FUgEBAQECAQEBEBERDAEBLAsBBAcEAgEIDgMEAQEBAgImAgICJQsVCAgCBAE?= =?us-ascii?q?NBQgagwGCRgMOIAECDKIVAoE4iGB1gTKCfgEBBYE1AYNdGIIXAwaBDigBjBY?= =?us-ascii?q?aggCBWIJMPoJkAQECgUsYgw4ygiyQIYVzmDoKgi6VdZomjkqaIwIEAgQFAg4?= =?us-ascii?q?BAQWBUjmBWHAVO4JsUBEUjGaDc4UUhT90AYEnjzABgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208";a="378518645" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 14:51:26 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6EpQ8O005769 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 14:51:26 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 08:51:26 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 09:51:25 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 08:51:25 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HwdZWIWxDs/j4wTKhFQLBwHe9PV5iOHwSHNRdH9KxmwBtVDhz2eGIOdHGKBxj53pM3jDGEwn3BAD+wXjx12HqtrrovbJQPFAizZZ/cTRCoo5u7nf+PvFCMODZxPwyQrj7yldsP+c7KoFp+lTRUhmY3Dr23sZKTnN8wU5hsndd5BS7qyZ//OjwJp9nDzjwBK+emKTeDC759RnBKrLX+G1etK+aIf0mzBVMamDSWKTOUiJTgPwJIvQ808R7Zl52Sem0KqhVT+RNZzWE5muQ+v2sdf5aFyELGZZ7wVYcjiq0F1UBab2AuuA+Xmo+d34IYToM9f5UOIn1c+vsaHt/3eV3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zD755vKnWIEIYEX/P5/SOZqUyb949PFpcQ+M2DGS9Xs=; b=Ihki1ZSng7V5TzdV+rzPMngN3rEPylt6h3rCIPdCCkfLNtLF0BhjtOruqiQoAKuOVMufs3SnWtvwL8skkGX7ygxfEh5ovCewPeh5AnxBr5Kv6DePUqLz/rNUNRixihmw2CKhc2EMmc0hyvAf3XeOM8jf/NmflulInbFdde0/K5CVvZVNisCzzwFELe/POvOtkqJtHsJhxi5Ts5LAlfzh8fWQa26/WBoOTqEr1ChmB+4/vPN6XEKUF/UCCGhpA8aaeBf+pfY1YrDnTa7s8zBOuyNfedXjxu7EyooNaIpZ85A1UcTqAeNaV9wy2UqfBsg7HdSie50b4iD57VSYFt9Mkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zD755vKnWIEIYEX/P5/SOZqUyb949PFpcQ+M2DGS9Xs=; b=wEfhwemofH6DfMshYIzMe4Ljz3G8jdyJNz4JQcXufb3UV1dUYyoOSDWlJKzIw/KWIechk9a4+fhQreX4l3Ajq4LaXnsrR2NYK7FX+uQ6jEAlALzuK8QwYO9k59Ifb8hu92UADRXc5UWGvz6U3/fgzEyXWkzwWdlP3tKl7lIBS04= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4220.namprd11.prod.outlook.com (52.132.251.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Fri, 6 Dec 2019 14:51:23 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 14:51:23 +0000 From: "Bernie Volz (volz)" To: Ted Lemon , Roy Marples CC: "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVq3nVccPHn0sPFUSCDdyJXpROxKetMbHQ Date: Fri, 6 Dec 2019 14:51:23 +0000 Message-ID: References: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.com> In-Reply-To: <7EC52F0F-DBB8-4339-89EE-5123DFAE415E@fugue.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=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9c4df68-9234-4b82-ae9e-08d77a5bc398 x-ms-traffictypediagnostic: DM6PR11MB4220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39860400002)(346002)(136003)(199004)(189003)(13464003)(2906002)(186003)(4326008)(5660300002)(8676002)(53546011)(8936002)(81156014)(6506007)(81166006)(26005)(102836004)(66946007)(9686003)(64756008)(66556008)(66476007)(71190400001)(66446008)(229853002)(33656002)(71200400001)(76116006)(55016002)(86362001)(76176011)(316002)(305945005)(7696005)(99286004)(74316002)(54906003)(478600001)(52536014)(966005)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4220; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PHsQA1YyOZ0/YOkQfsasbmTE0fbpNRxM8QpPxgKoOEGq51PYpV5H0Cq6Hpdk6VVn09KAOz/2p+5pAlGZJSh+mGbut1YGjZd+pMEq89ULeKPrQrqXJuT+RGsGCcNxB+Kekjbpk14767mmAWX6Di7aQk5zaTDmBrDLzZ+uAnUhd4uAKe+rcuo8hWAk5tPsB6UvlcCOlK0SKqtE7wt/iJi0x93xxAbOoOKN8I1qlIUFAzSr7sDXtcA4hFbHyK/xWPq0jU49wae/BUztEyNB3Wpk6v8iBkaxpI4pekZq2b2ONla5k+fbA1jcqVnVzBkheZieWyyeUts8dDwidFyd6QDnjhJCqY1U4qz2+83VTjOI48iMh7St2fIpf6v2svr+vPWneJ+lhV1OWoODOow+xAaOpdmcM1CzQENeY8eAFZOgTdFo+NhComiLEFsLT6VSRUZlgkgajeMlApkd5jmql9utUAZBkOWToFGInRJOdsfsYS9mZWvUlVptUkVriJY4TH4FqJrpiakayeUK2ZXgY2Ev1HVYxj8j/waMqqt/GgNRt5Q= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c9c4df68-9234-4b82-ae9e-08d77a5bc398 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 14:51:23.7580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 77i7oFxkJEYbXPlJ7NomK+C6acZ0dhY4RpYe8jrBiyHdYukBnqNh8/snYqT1BHWl X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4220 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:51:31 -0000 PiBUaGVyZSBpcyBhIHJlYXNvbiB3aHkgREhDUCBpbmNsdWRlcyBhIHBhcmFtZXRlciByZXF1ZXN0 IGxpc3Qgb3B0aW9uLiAgSWYgdGhlIGNsaWVudCBkb2VzbuKAmXQgYXNrIGZvciB0aGlzIG5ld2Zh bmdsZWQgb3B0aW9uLCBpdCBzaG91bGRu4oCZdCBzZWUgaXQuICBBbmQgc28gd2UgY2FuIGtub3cg Zm9yIHN1cmUgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIHRoaXMgY2FwYWJpbGl0eSwgYmVjYXVz ZSBpdCBhc2tlZCBmb3IgaXQuDQoNCkV2ZW4gaWYgYSBESENQIHNlcnZlciBzZW50IHRoZSBvcHRp b24gd2l0aG91dCBpdCBiZWluZyByZXF1ZXN0ZWQsIHdoeSB3b3VsZCB0aGUgY2xpZW50IHVzZSBp dCBpZiBpdCBkaWRuJ3QgYXNrIGZvciBpdD8NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgVGVkIExlbW9uDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNSwgMjAxOSA5OjM5IEFN DQpUbzogUm95IE1hcnBsZXMgPHJveT00MG1hcnBsZXMubmFtZUBkbWFyYy5pZXRmLm9yZz4NCkNj OiBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPjsgZHJhZnQtbGlu ay1kaGMtdjZvbmx5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBbZGhjd2ddIElQdjYt T25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbg0KDQpPbiBEZWMgNCwgMjAxOSwgYXQgODo0NiBQ TSwgUm95IE1hcnBsZXMgPHJveT00MG1hcnBsZXMubmFtZUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6 DQo+IFNvIGluIHNpbXBsZSB0ZXJtcy4NCj4gVGhlIHNlcnZlciBvZmZlcnMgc29tZSBpbmZvcm1h dGlvbi4NCj4gR2l2ZW4gdGhpcyBpbmZvcm1hdGlvbiAoaW4gY3VycmVudCBESENQIHNlbWFudGlj cykgd2UgY2FuIFJFTkVXIChUMSkgb3IgUkVCSU5EIChUMikuDQo+IElmIHRoZSBjbGllbnQgZG9l cyBub3QgcmVxdWVzdCB0aGUgb2ZmZXIgKGhleSEgSSBzZWUgdGhpcyBuZXcgZmFuZ2xlZCBvcHRp b24gaGVyZSB0aGF0IHNheXMgTk8gREhDUCkgdGhlIGNsaWVudCBjYW4gc3RpbGwgYWNjZXB0IHRo ZSBUMiB0aW1lciBhdCB0aGUgdmVyeSBsZWFzdC4NCj4gDQo+IFRoaW5rIG9mIHRoZSBhbmFsb2d1 cyBSRkMgNzA4MyAtIE1vZGlmaWNhdGlvbiB0byBEZWZhdWx0IFZhbHVlcyBvZiBTT0xfTUFYX1JU IGFuZCBJTkZfTUFYX1JULiBUaGlzIFJGQyBnb2VzIG91dCBvZiBpdHMgd2F5IG5vdCB0byBhZGQg bmV3IHRpbWVycy4NCg0KVGhlcmUgaXMgYSByZWFzb24gd2h5IERIQ1AgaW5jbHVkZXMgYSBwYXJh bWV0ZXIgcmVxdWVzdCBsaXN0IG9wdGlvbi4gIElmIHRoZSBjbGllbnQgZG9lc27igJl0IGFzayBm b3IgdGhpcyBuZXdmYW5nbGVkIG9wdGlvbiwgaXQgc2hvdWxkbuKAmXQgc2VlIGl0LiAgQW5kIHNv IHdlIGNhbiBrbm93IGZvciBzdXJlIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0aGlzIGNhcGFi aWxpdHksIGJlY2F1c2UgaXQgYXNrZWQgZm9yIGl0Lg0KDQpJcyB0aGVyZSBhbnkgcmVhc29uIHdo eSB3ZSAvd291bGRu4oCZdC8gd2FudCB0byBkbyB0aGlzPw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Fri Dec 6 06:57:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E691200C5 for ; Fri, 6 Dec 2019 06:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 OafdpXnVGyP1 for ; Fri, 6 Dec 2019 06:57:32 -0800 (PST) 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 DFF95120020 for ; Fri, 6 Dec 2019 06:57:31 -0800 (PST) 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 m1idF2w-0000JbC; Fri, 6 Dec 2019 15:57:30 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <20191206123936.GP72330@Space.Net> <20191206143831.GQ72330@Space.Net> In-reply-to: Your message of "Fri, 6 Dec 2019 15:38:31 +0100 ." <20191206143831.GQ72330@Space.Net> Date: Fri, 06 Dec 2019 15:57:30 +0100 Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:57:33 -0000 >What a horrible way! Forcing your users behind a NAT! It's a legacy protocol. If users want a routable address, they can use IPv6. This is only for connecting to less advanced parts of the internet. (I have to admit there does also seem to be a lot of NAT without IPv6) >What's the rationale for forcing NAT44 on your users? I think you provided the rational earlier: running out of IPv4 addresses. In any case, NAT64 is also NAT. For users, there is not a big difference between NAT44 and NAT64. In my opinion, NAT44 is better than NAT64, but the difference is not big. >(Speaking of a certain dual-stack ssid, why are we offering public v4 >there?) Possibly because there is no other use for those addresses :-) From nobody Fri Dec 6 06:59:49 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8B1200C5; Fri, 6 Dec 2019 06:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=E/DH1HQs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MY4eK9Lu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrenV3qzStyM; Fri, 6 Dec 2019 06:59:41 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DA4120020; Fri, 6 Dec 2019 06:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13080; q=dns/txt; s=iport; t=1575644380; x=1576853980; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xL2peSIRampG9UM4GLNi9YQ+ZOPjymK12o0iCCKrr5I=; b=E/DH1HQsAKRCuEDBgb7sXyI2W8nuOFOt9NrdNGqsdJc24jdjZgIMhAx5 g7+OoTZarQnOPBYgAZH57VdhEWtxlz7GM67lHjpweVtVVwAi0f0E0h0ZL tJh2rlifvMU3hUyZl5cSRkkOuXo1tbJis8YBvq+qWORnMJlJV8V3nc7Xs A=; IronPort-PHdr: =?us-ascii?q?9a23=3A9K6eqxCWkAIVXdY84DlLUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFP8KOzCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBQCibOpd/5RdJa1bCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF+gRwvJCwFbFggBAsqCoQhg0YDin6CX4lbiUeEYoFCgRADVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4F+JDgTAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQEDEhE?= =?us-ascii?q?KEwEBNwEPAgEIEQQBASgDAgICHxEUCQgCBAENBQgagwGBeU0DLgECohkCgTi?= =?us-ascii?q?IYHWBMoJ+AQEFhRoNC4IXCYE2jBcaggCBEUeCTD6CG4F7AQgKAQkYNIJaMoI?= =?us-ascii?q?skCGFTySXeEIKgi6RP4Q2miaOSopXj0wCBAIEBQIOAQEFgWkiZ3FwFTuCbFA?= =?us-ascii?q?RFIxmg3OKU3SBKI4OgSIBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208,217";a="378469421" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 14:59:30 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6ExUQ5006559 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 14:59:30 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 08:59:29 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 08:59:29 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 09:59:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GCd6CcbwYqi2OqIqe54YGqcrI8BTIj6NlRFSHF2XoEBR5v2XLicEEU7yPO6dN3aqJKQMmjxr3ufkd+8H9e/sjHsWMDXEgBJcsKZavckbHsHR2wLYlqCp3QwXYTAVK7NIet0OONcpkgdkHkXFcxGl3093BRx739CWCO0sBjtM8iVBukolIeEW5rnu4LfM/McJQn3j+IwGnpXbLyotjaZZZifEA6RyaSg/9/7u28HoA+9E6461xG70QLPskH2omSx2HHNafw8spff6MRzkAskwPxBp/UNdQ8M0xzKqzqHiMtedNvEbP4uJid1+VDE+K7i8QDIMJ6556VBqjz7j8yp9oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xL2peSIRampG9UM4GLNi9YQ+ZOPjymK12o0iCCKrr5I=; b=S1nN7IldhVPNEydGreRve7lhKdFi6ItnXRMgc4+bsjXrr+Mhu2fRxbuJaTjKtKCeZUL5kTM2c/KyJQEoOlkLUnK9ZCSvmHeZGcC5/xphsN8Nnfq8c+I2NOb+1aidRnE5XtrnFATvqdFTJUkGlNGIlZKFq3DinQx4WIu5u1ccJDUsen12CqKNx62U2ImyOFMUdJW8vAv2N7WstyN11hHSOeZsFCV72HJrOK2HLsg5B13Gm4+5/IQvpOIbdOF4xS64gl1uAWQ6IPiNDdrNsutFjyV+Hq8YVRc0y2X2JYtMJnaHm9pp7feQdNkDjQQ0gpjIEjic8vBQWadsHAMYsrjWJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xL2peSIRampG9UM4GLNi9YQ+ZOPjymK12o0iCCKrr5I=; b=MY4eK9Lupq11PAoUgp2JFZEWYjX0WZ89h1VSdT2B4FLSjmRbBmlLZC3URf31fcegwK7gzlLjI+3VharbZpA2X4rQ3lEb0wsolLXSK5yqIdC5j2lQJeiyoyGWv1RdzZHG40/pEixAxC2qrgqs1hb1OAn5LmriHzJR4qVQoZnPF7U= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4220.namprd11.prod.outlook.com (52.132.251.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Fri, 6 Dec 2019 14:59:28 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 14:59:28 +0000 From: "Bernie Volz (volz)" To: Lorenzo Colitti , Jen Linkova , Tomek Mrugalski CC: V6 Ops List , "draft-link-dhc-v6only@ietf.org" , "dhcwg@ietf.org" , "Michael Richardson" Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrEXBZ9rqhGZ/IUaWcKhj5j3PcA== Date: Fri, 6 Dec 2019 14:59:28 +0000 Message-ID: References: <28594.1575483729@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61cede51-4f2b-4533-0be6-08d77a5ce471 x-ms-traffictypediagnostic: DM6PR11MB4220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39860400002)(346002)(136003)(199004)(189003)(2906002)(186003)(4326008)(5660300002)(8676002)(53546011)(8936002)(81156014)(6506007)(81166006)(26005)(102836004)(790700001)(66946007)(9686003)(64756008)(66556008)(66476007)(71190400001)(66446008)(229853002)(33656002)(71200400001)(76116006)(55016002)(86362001)(76176011)(316002)(7696005)(54896002)(99286004)(74316002)(54906003)(478600001)(52536014)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4220; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BtTYa/i0W4Kx3ut7cg+0Zs16dw+VGgrXoh+fxEZexlilhiPOwt2pNlZvh+rC8h0e3JYTTw27wN0QkmEIJZHZS5rsCw4ZUaF7bqfYx64kEtMPOGJeuXALRy4VdzBDL7UdkZ+0u4QdLjMvdp3GKnJ7k4hkqA9+BxdgudbWFD1Wp0wBzX0yv5ryDIe26s+GSklSHz5mY7tSHFZDBWw3gv19hS6pgtx0mybcfqdI+rTD7WPppYvzi316TmnywXEZB4mjTN7y0LvoYpVdZDSp2M74Bo3t7SsZrEiZ0ml/C6YjdkGDKuLcavnwQLbd0Tl0fNfOxk0c4aVQ2VyxJTeVzXloIDGE0qM9O4zfkSVMIb80iTcrPGK2JqUnXpC/9QZ0jTZQz4eag5NEOkQ7m2C4eWNHMTGJvWQr46JDM3j7gJodGzel5uFT/3fury1qAWWWbaZV x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB4137A537075D4D90732F7EB4CF5F0DM6PR11MB4137namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 61cede51-4f2b-4533-0be6-08d77a5ce471 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 14:59:28.3079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n244DcuKhKsQ2z2sd+AGjuL18094/gbQXldPdZerdHrHEdNB6WQ/x9f3/TK0qRPv X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4220 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 14:59:43 -0000 --_000_DM6PR11MB4137A537075D4D90732F7EB4CF5F0DM6PR11MB4137namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIExvcmVuem8uIEtlZXAgaXQgc2ltcGxlIChzZWUgcHJldmlvdXMgZW1haWwg dGhhdCB0aGVyZSByZWFsbHkgc2hvdWxkIGJlIG5vIHdvcmsgb24gdGhlIERIQ1Agc2VydmVycyB0 byBzdXBwb3J0IHRoaXMgY2FwYWJpbGl0eSkuDQoNClllcywgeW91IGNvdWxkIHJlc2VydmUgYW4g YWRkcmVzcywgYnV0IEkgZG9u4oCZdCBzZWUgdGhhdCBhcyByZXF1aXJlZC4gTm90ZSB0aGF0IEkg aGFkIHN1Z2dlc3RlZCB0aGlzIHRvIHRoZSBhdXRob3JzIGJlZm9yZSB0aGUgZHJhZnQgd2FzIHB1 Ymxpc2hlZCBhcyBhbiBvcHRpbWl6YXRpb247IEkgZG9u4oCZdCB0aGluayBpdCBzaG91bGQgYmUg dGhlIG5vcm0uIEFuZCB3aXRoIG1hbnkgc2VydmVycywgeW91IGNvdWxkIHByb2JhYmx5IGp1c3Qg ZG8gdGhpcyB2aWEgY29uZmlndXJhdGlvbiAoaS5lLiwgaWYgUFJMIGNvbnRhaW5zIOKAnElQdjYt T25seeKAnSBvcHRpb24sIG92ZXJyaWRlIHRoZSBjbGllbnQgaWRlbnRpdHkgd2l0aCBhIGZpeGVk IHVuaXF1ZSBuYW1lLCBhZGQgYSBmaXhlZCBhZGRyZXNzIC8gcmVzZXJ2YXRpb24gZm9yIHRoYXQg dW5pcXVlIG5hbWUpLg0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogRnJpZGF5 LCBEZWNlbWJlciA2LCAyMDE5IDI6MjEgQU0NClRvOiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFp bC5jb20+OyBUb21layBNcnVnYWxza2kgPHRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPg0KQ2M6 IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz47IGRyYWZ0LWxpbmstZGhjLXY2b25seUBpZXRm Lm9yZzsgZGhjd2dAaWV0Zi5vcmc7IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVs bWFuLmNhPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gW2RoY3dnXSBJUHY2LU9ubHkgUHJlZmVycmVk IERIQ1B2NCBvcHRpb24NCg0KT24gRnJpLCBEZWMgNiwgMjAxOSBhdCA0OjE0IFBNIEplbiBMaW5r b3ZhIDxmdXJyeTEzQGdtYWlsLmNvbTxtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20+PiB3cm90ZToN CiJJZiB0aGUgcG9vbCBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgd2l0aCBhIGRlZGljYXRlZCBJ UHY0DQogICBhZGRyZXNzIHRvIGJlIHJldHVybmVkIHRvIElQdjYtb25seSBjYXBhYmxlIGNsaWVu dHMgdGhlIHNlcnZlciBNVVNUDQogICBzcGVjaWZ5IHRoYXQgYWRkcmVzcyBhcyB0aGUgY2xpZW50 J3MgbmV0d29yayBhZGRyZXNzIGFuZCBNVVNUIE5PVA0KICAgdmVyaWZ5IGl0cyB1bmlxdWVuZXNz Lg0KDQpUaGF0IHNlZW1zIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgb24gdGhlIHNlcnZlci4gV2h5 IG5vdCBqdXN0IHJldHVybiBhIG5vcm1hbCBPRkZFUiBmcm9tIHRoZSBwb29sPyBUaGF0IHdheSwg aWYgc29tZXRoaW5nIHVuZXhwZWN0ZWQgaGFwcGVucyBhbmQgdGhlIGNsaWVudCBzZW5kcyBhIERI Q1BSRVFVRVNUIGZvciBpdCwgdGhlIHNlcnZlciBjYW4gaGFuZCBpdCBvdXQgYXMgbm9ybWFsLg0K DQpUaGUgYWx0ZXJuYXRpdmUgaXMgcmlza3kuIElmIHRoZSBzZXJ2ZXIgdXNlcyBhIGJvZ3VzIE9G RkVSIHZhbHVlLCBhbmQgc29tZSBjbGllbnQgcmVxdWVzdHMgaXQgYW5kIHRoZSBzZXJ2ZXIgaGFu ZHMgaXQgb3V0LCB0aGF0IGNyZWF0ZXMgdGhlIHBvc3NpYmlsaXR5IGZvciBtaXNjb25maWd1cmF0 aW9uIG9yIGJ1Z3MgdG8gY3JlYXRlIHJlYWxseSBiYWQgb3V0Y29tZXMgd2hlcmUgbXVsdGlwbGUg aG9zdHMgaGF2ZSB0aGUgc2FtZSBJUCBhZGRyZXNzLCBvciBzb21lIHRoaW5ncyBvbiB0aGUgbmV0 d29yayAoZS5nLiwgc25vb3Bpbmcgc3dpdGNoZXMpIHRoaW5rIHRoYXQgbXVsdGlwbGUgaG9zdHMg aGF2ZSB0aGUgc2FtZSBJUCBhZGRyZXNzLiArVG9tZWsgTXJ1Z2Fsc2tpPG1haWx0bzp0b21hc3ou bXJ1Z2Fsc2tpQGdtYWlsLmNvbT4gYW55IHRob3VnaHRzIG9uIHdoZXRoZXIgdGhpcyBjYW4gYmUg aW1wbGVtZW50ZWQgZWFzaWx5IGFuZCByZWxpYWJseSBvbiB0aGUgc2VydmVyIHNpZGU/DQo= --_000_DM6PR11MB4137A537075D4D90732F7EB4CF5F0DM6PR11MB4137namp_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU2NzY4OTMwMzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM3OTU0NDUwIC0zNzgxNDA1MjggNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIExvcmVuem8uIEtlZXAgaXQgc2ltcGxlIChzZWUgcHJl dmlvdXMgZW1haWwgdGhhdCB0aGVyZSByZWFsbHkgc2hvdWxkIGJlIG5vIHdvcmsgb24gdGhlIERI Q1Agc2VydmVycyB0byBzdXBwb3J0IHRoaXMgY2FwYWJpbGl0eSkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlllcywgeW91IGNvdWxkIHJlc2VydmUgYW4gYWRkcmVzcywgYnV0IEkgZG9u4oCZdCBz ZWUgdGhhdCBhcyByZXF1aXJlZC4gTm90ZSB0aGF0IEkgaGFkIHN1Z2dlc3RlZCB0aGlzIHRvIHRo ZSBhdXRob3JzIGJlZm9yZSB0aGUgZHJhZnQgd2FzIHB1Ymxpc2hlZCBhcyBhbiBvcHRpbWl6YXRp b247IEkgZG9u4oCZdCB0aGluayBpdCBzaG91bGQgYmUgdGhlIG5vcm0uIEFuZCB3aXRoIG1hbnkg c2VydmVycywgeW91IGNvdWxkDQogcHJvYmFibHkganVzdCBkbyB0aGlzIHZpYSBjb25maWd1cmF0 aW9uIChpLmUuLCBpZiBQUkwgY29udGFpbnMg4oCcSVB2Ni1Pbmx54oCdIG9wdGlvbiwgb3ZlcnJp ZGUgdGhlIGNsaWVudCBpZGVudGl0eSB3aXRoIGEgZml4ZWQgdW5pcXVlIG5hbWUsIGFkZCBhIGZp eGVkIGFkZHJlc3MgLyByZXNlcnZhdGlvbiBmb3IgdGhhdCB1bmlxdWUgbmFtZSkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5C ZXJuaWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHY2b3BzICZs dDt2Nm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTG9yZW56 byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgNiwgMjAxOSAyOjIx IEFNPGJyPg0KPGI+VG86PC9iPiBKZW4gTGlua292YSAmbHQ7ZnVycnkxM0BnbWFpbC5jb20mZ3Q7 OyBUb21layBNcnVnYWxza2kgJmx0O3RvbWFzei5tcnVnYWxza2lAZ21haWwuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gVjYgT3BzIExpc3QgJmx0O3Y2b3BzQGlldGYub3JnJmd0OzsgZHJhZnQtbGlu ay1kaGMtdjZvbmx5QGlldGYub3JnOyBkaGN3Z0BpZXRmLm9yZzsgTWljaGFlbCBSaWNoYXJkc29u ICZsdDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Y2b3BzXSBbZGhjd2ddIElQdjYtT25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDYsIDIwMTkgYXQg NDoxNCBQTSBKZW4gTGlua292YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZ1cnJ5MTNAZ21haWwuY29t Ij5mdXJyeTEzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0lmIHRoZSBw b29sIGlzIGV4cGxpY2l0bHkgY29uZmlndXJlZCB3aXRoIGEgZGVkaWNhdGVkIElQdjQ8YnI+DQom bmJzcDsgJm5ic3A7YWRkcmVzcyB0byBiZSByZXR1cm5lZCB0byBJUHY2LW9ubHkgY2FwYWJsZSBj bGllbnRzIHRoZSBzZXJ2ZXIgTVVTVDxicj4NCiZuYnNwOyAmbmJzcDtzcGVjaWZ5IHRoYXQgYWRk cmVzcyBhcyB0aGUgY2xpZW50J3MgbmV0d29yayBhZGRyZXNzIGFuZCBNVVNUIE5PVDxicj4NCiZu YnNwOyAmbmJzcDt2ZXJpZnkgaXRzIHVuaXF1ZW5lc3MuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNlZW1zIGRpZmZpY3Vs dCB0byBpbXBsZW1lbnQgb24gdGhlIHNlcnZlci4gV2h5IG5vdCBqdXN0IHJldHVybiBhIG5vcm1h bCBPRkZFUiBmcm9tIHRoZSBwb29sPyBUaGF0IHdheSwgaWYgc29tZXRoaW5nIHVuZXhwZWN0ZWQg aGFwcGVucyBhbmQgdGhlIGNsaWVudCBzZW5kcyBhIERIQ1BSRVFVRVNUIGZvciBpdCwgdGhlIHNl cnZlciBjYW4gaGFuZCBpdCBvdXQgYXMgbm9ybWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYWx0ZXJuYXRpdmUgaXMgcmlza3kuIElm IHRoZSBzZXJ2ZXIgdXNlcyBhIGJvZ3VzIE9GRkVSIHZhbHVlLCBhbmQgc29tZSBjbGllbnQgcmVx dWVzdHMgaXQgYW5kIHRoZSBzZXJ2ZXIgaGFuZHMgaXQgb3V0LCB0aGF0IGNyZWF0ZXMgdGhlIHBv c3NpYmlsaXR5IGZvciBtaXNjb25maWd1cmF0aW9uIG9yIGJ1Z3MgdG8gY3JlYXRlIHJlYWxseSBi YWQgb3V0Y29tZXMgd2hlcmUgbXVsdGlwbGUgaG9zdHMgaGF2ZQ0KIHRoZSBzYW1lIElQIGFkZHJl c3MsIG9yIHNvbWUgdGhpbmdzIG9uIHRoZSBuZXR3b3JrIChlLmcuLCBzbm9vcGluZyBzd2l0Y2hl cykgdGhpbmsgdGhhdCBtdWx0aXBsZSBob3N0cyBoYXZlIHRoZSBzYW1lIElQIGFkZHJlc3MuJm5i c3A7PGEgaHJlZj0ibWFpbHRvOnRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tIj4mIzQzO1RvbWVr IE1ydWdhbHNraTwvYT4mbmJzcDthbnkgdGhvdWdodHMgb24gd2hldGhlciB0aGlzIGNhbiBiZSBp bXBsZW1lbnRlZCBlYXNpbHkgYW5kIHJlbGlhYmx5DQogb24gdGhlIHNlcnZlciBzaWRlPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DM6PR11MB4137A537075D4D90732F7EB4CF5F0DM6PR11MB4137namp_-- From nobody Fri Dec 6 07:25:44 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797AF120836; Fri, 6 Dec 2019 07:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 7_CmWNv0KLDG; Fri, 6 Dec 2019 07:25:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C6412082D; Fri, 6 Dec 2019 07:25:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 14C623818F; Fri, 6 Dec 2019 10:22:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E659366; Fri, 6 Dec 2019 10:25:40 -0500 (EST) From: Michael Richardson To: Jen Linkova cc: David Farmer , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org In-Reply-To: References: <28594.1575483729@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 15:25:43 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: > The draft currently suggests that the server is configured with a > dedicated IPv4 address per pool for this purpose: > "If the pool is explicitly configured with a dedicated IPv4 > address to be returned to IPv6-only capable clients the server MUST > specify that address as the client's network address and MUST NOT > verify its uniqueness. Otherwise the server SHOULD follow the > recommendations in [RFC2131]. The client is not expected to use that > IPv4 address so if the client responds with the DHCPREQUEST message > for that address the server SHOULD respond with DHCPNAK. > " This is why this document belongs in DHC, because this is new server logic :-) I think that maybe we are trying to be too cute here. The goal is not to assign an address, but ciaddr is a fixed field, so we have to put something in, and I think that we are worried that 0.0.0.0 is going to confuse DHCP relay nodes that snoop. At this point, Jen is trying to give the DHCP administrator some rope with which to work around confusing the snoop node by creating a pool of one address. Maybe we can return 225.0.0.1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3qcvQACgkQgItw+93Q 3WUUAQgAoydphL+WDado+FjgN8GLhftAZj0kVmMgndb6QLj7/70Sw+cq8Vcw+/vu KRlN7wyXiowWT2hlhItFkm+Aj+xEO3IwEnYCDRPKxDSeHTdccK2gcDJCgMQrx+Ut fZozRTPouBk6iGHKTX+UK9dGBrkwhYcYewWenxdCIEA3a+UJnIcMQOLCrPyWD+Cc SVHnXMn+tDc9tiXMXCXObH/l/VXJlMlRQuGChlWUZGoQ83lePNcrwgDQ/Y0XnBkI UokYkxCnGITL1MLBluYEZ+Rpdyd80/t4tmckIqIUbsZzR5RIQTxFbp6DH7J7b0W0 hUEUAaRLCrRb9bX88Gnp5nKTTtjWoQ== =Gf1l -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 6 08:00:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45086120020; Fri, 6 Dec 2019 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=aGRfZ8B7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XQJwHVBR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy1qZOWMGrj7; Fri, 6 Dec 2019 07:59:55 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322E3120019; Fri, 6 Dec 2019 07:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1925; q=dns/txt; s=iport; t=1575647995; x=1576857595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w2DbYUwTmRi8UfbGaWXh3o5lrr45eSQc4HCEZBF2bUE=; b=aGRfZ8B7iuOgcPYXQoAZDXk/kX6HUiG4biCT58JqK2PSP2bvUv2vmCOf l5Oesuo+p/WFEHQ265pSJ10qgCLYtANBLIKxB+Tf4I1LZCdUNVjH7elHZ Snmy81QUl8rwhiaSKMXPt97JTY7mUvYrYk/F3ssBoZhW6LorSjHZPJUr7 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A8sRnNhFt7XoG/yUN4RQKE51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjlK/r4Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAAfeupd/4ENJK1kGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagYBAQELAYFKKScFbFggBAsqCodnA4RahiOCX4lbjim?= =?us-ascii?q?BLhSBEANUCQEBAQwBASMKAgEBgUyCdAKCFSQ0CQ4CAw0BAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVSAQEBAQMSKAYBATcBCwQCAQgRBAEBAR4QIREdCAIEAQ0FCBqDAYJGAy4?= =?us-ascii?q?BAgyiNAKBOIhggieCfgEBBYUTDQuCFwMGgTYBjBYaggCBEUeCTD6CG0kCgTA?= =?us-ascii?q?BEgEJGINAgiyuDEIKgi6HH4oghDaaJo5KiEGCFo9MAgQCBAUCDgEBBYFSOWd?= =?us-ascii?q?xcBU7gmxQERSMZgeBIAEMgj+FFIU/dIEojX8PFwSBBwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208";a="378176320" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 15:59:54 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6Fxs2W013448 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 15:59:54 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 09:59:53 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 09:59:52 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 09:59:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XgX54FeLefmDv+EWRrL1LOuQh8JxBHYx0LjdT1OlIPIFcDqeotgmdq0dRRluB1YhFYvBoSIzTWRT83sR6pWUXMXfMDB+SB4Yfnuay/TvF4re7C8BPESzrAzjyeIskvpvdbYAnAmzO2nzahWdDur1loJqbRLzkGNiCTS68b5NQulT6RMMhoBPL/L761yF5h6uKtjRloMV6M1KNuGyfHul5g2MV7Fe2192FDbSEAdObKT34X8XOwHtyiNtro+jbQDei/KrbSzrhAR8A4vAivrfC3HtHBRp3SVlmGzx7yGcRGv+Km66nzFnSBSJLsfaf1iFrRA2L8aoymxKN+mb4dLaiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8nGXHxlptTj8RgZQE9y5ODYk6kU+BOa4hikCSiGaWfE=; b=h0n8Mgab9zpD0D8tkp2DlD9IdNuA+5CsGSfszp2bWLmXpYG8G35v742rRluOn9ayYQTckZHDbX+RUgeupemDJmAarCKHvSeDBqkODZAGHOIbrDeCS3wOyWsRrU6ToehwGuNhp39hPkbVv/XW4L0yA8g1XR+LKdNqr97VgrYnYuRsC8z2+Wf1il6qxEq3q/irijDc3xGf4FjEpLWr1C4BX6tfL3O54EdEL3z/YvJsKgqPzaH+zsfLWOVnzksjsRGGnt0i+t4tEqueVOuaZ+FUqJXVSxs3FFwlOQB6ehp+5atMbVj50FNG31j15qI5YGeEiSVZ9LHBWffcURVgCFefLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8nGXHxlptTj8RgZQE9y5ODYk6kU+BOa4hikCSiGaWfE=; b=XQJwHVBR5B+8tob3anIRM53R8pcyopzhucXW4/qvrGelmkOvU+GeYKxhZZxMtu+Cdyp7V3BtAH4Y7hcw6ptQo1x4s4CVdBhb7s2Yici8AI8GWUVME84MlNQQCGiEjY3DzCPA+Q77a2SA/d3wkIB5zO2enaAiIzrZJqGqkp7VED8= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB2553.namprd11.prod.outlook.com (20.176.95.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Fri, 6 Dec 2019 15:59:51 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 15:59:51 +0000 From: "Bernie Volz (volz)" To: Michael Richardson , Jen Linkova CC: V6 Ops List , "draft-link-dhc-v6only@ietf.org" , "dhcwg@ietf.org" Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrE4xZsIh5m/8hUqHWdac1sci3A== Date: Fri, 6 Dec 2019 15:59:51 +0000 Message-ID: References: <28594.1575483729@localhost> <5391.1575645940@localhost> In-Reply-To: <5391.1575645940@localhost> 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=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45e9dbc1-3b39-4468-ec6c-08d77a65542b x-ms-traffictypediagnostic: DM6PR11MB2553: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(396003)(346002)(376002)(13464003)(51444003)(199004)(189003)(66556008)(66476007)(76116006)(52536014)(102836004)(316002)(229853002)(5660300002)(66446008)(478600001)(55016002)(99286004)(4326008)(76176011)(53546011)(64756008)(9686003)(6506007)(7696005)(33656002)(186003)(54906003)(110136005)(2906002)(66946007)(8936002)(81156014)(26005)(74316002)(71190400001)(71200400001)(86362001)(81166006)(305945005)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2553; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hlbrILyy2IFdc82mmlyseOOBnhX/ptz71udT+peG5B+IqKHNXVeIKEsJa5PXYUycOPlZy7391ZjyVtgSW6L6JqxPqoBspz+aEtRYD99FIp2dMpeQOKjRdzHvqTUaUA5A/KVLB23mX9n4s7JzUItJeusdJLSm3RqX3kxU6chUmT+BHuc+YMus8kMshpFGJB0b5FRoBpU27pAYWIq/TgmCQZ4C0bD5XFXQdlyQroDSwQyJjHzMHN4x9T58Uk/L2BJe4paMY1TEjksydoib1S4sWwrL8AXfxnfklM1xXz7agL4OUV1XZOE0zeW4phF4ui5jFYLjb9uhjuarAR7qRVJQVf5fem7tbMNNGmUeeC4qI5NbRrOU/8Tt4r08870/zs27iJDmEz7M0YxYFxcw+1PzE7yuXU5NXQtQX5/5LXpd+tRIbifo95nvmmkAC2s9YT9LVc3Zuw5V3Jya3yvlQZT/nfIaIo27FzqK5AZ5rr6KSem8vzuSt78miCUfiq6haT5dbBxWs+4A75zinAyJobxpKK89cknf1W4taVOJ04J+dfZZzqDnU9Z9U1poQ0BL9Dnc x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 45e9dbc1-3b39-4468-ec6c-08d77a65542b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 15:59:51.7125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qP8pDDuMEdQCV02qFZCZNcOD9sUwMoNaHedTmtPTQdFQbrB34HGXUkK+BBYyQM1j X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2553 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 15:59:58 -0000 I would keep it simple and not change the server's processing with respect = to the a (temporarily) assigned address in the DHCPOFFER. See my other email on the topic (https://mailarchive.ietf.org/arch/msg/dhcw= g/T_5gklM3klgjHeMOlOhEF4e-IWI). - Bernie -----Original Message----- From: v6ops On Behalf Of Michael Richardson Sent: Friday, December 6, 2019 10:26 AM To: Jen Linkova Cc: V6 Ops List ; draft-link-dhc-v6only@ietf.org; dhcwg@iet= f.org Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option Jen Linkova wrote: > The draft currently suggests that the server is configured with a > dedicated IPv4 address per pool for this purpose: > "If the pool is explicitly configured with a dedicated IPv4 > address to be returned to IPv6-only capable clients the server MUST > specify that address as the client's network address and MUST NOT > verify its uniqueness. Otherwise the server SHOULD follow the > recommendations in [RFC2131]. The client is not expected to use that > IPv4 address so if the client responds with the DHCPREQUEST message > for that address the server SHOULD respond with DHCPNAK. > " This is why this document belongs in DHC, because this is new server logic = :-) I think that maybe we are trying to be too cute here. The goal is not to assign an address, but ciaddr is a fixed field, so we ha= ve to put something in, and I think that we are worried that 0.0.0.0 is goi= ng to confuse DHCP relay nodes that snoop. At this point, Jen is trying to give the DHCP administrator some rope with = which to work around confusing the snoop node by creating a pool of one add= ress. Maybe we can return 225.0.0.1. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Dec 6 08:02:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5637B12004F for ; Fri, 6 Dec 2019 08:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMR0Xtf6R52X for ; Fri, 6 Dec 2019 08:02:05 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D78E120020 for ; Fri, 6 Dec 2019 08:02:05 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id w5so2901064pjh.11 for ; Fri, 06 Dec 2019 08:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4wuAXSpam1y+5kPi3mKVjS09Lmuhuw3ddXZqgv6siv0=; b=KjOU+haxedidBQqviy0Cnab+z9p8jCSRE3ZYcZCi4QChTSAqSOEQdFYmwyGGAePvHa 7ZqLzdzCDh+xH9juOn231blB1EBjAX2Sftav6UA0favhx3Kr1w5Xl4mkRBifdvG4Y6O5 LiUsW7yEo21lsMtWE28dmjcdWRY7AkNcf0BMTUx6nLrztL4I2E8PjGQtYQakHuT7t1a8 mJmtKTIPpaqIbnBwn3qgVUbrnofH4CRq7BGkOtE8ihEQqmHDCK1ezDzx4BCUiJRFmJAY 7e3v5BDtm2gHygnB7P2IhlzNgNMVMBuaDMOG0e9oe9Xq8WaqipzD0ixkCeecS5F/nx43 U52Q== 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=4wuAXSpam1y+5kPi3mKVjS09Lmuhuw3ddXZqgv6siv0=; b=oJBRjuqgA8TkxuQ/FuT/zD5R/bAjpZ+SB4wVZoxSNu5f8dremIfVcISTKT5sPRRR7S gdlv0zmVY8eLedp2QHk8hbbqB0oEVUobHnak6jTkaWVWJB0ptqmRYpfgVN5Nc2idPrAY ECnnTdLxnhxqctjLBjj7bIpbrumPfFEYjNfim8xBOXC4j+Xjsaay2MaEOQ/LA4yIhGEI D5cz4BDQFDig6mw+6i+bbWHwFKBDeB05zVQDKbnZRuOgwmdALkAPqcpFdOyvRwVjTcOg M38bAzi7CnQr4QW8no9T7ognaaERbj9UsNAApa2bLXPUePD84NxsYbFwFxtRlAbw5Vz1 phQw== X-Gm-Message-State: APjAAAUjnFkQovjWc84cJc5Z1CNLFuvPQd9FapJFBej4j09AG03olHvU 37SeAbSIXmslV9mJTll2206mCQ== X-Google-Smtp-Source: APXvYqxSaPc3eh8YZ182s1e7csUS1YlDcqCR2u9KTn13zuVI2iMrnKfkL16Sj07W/PusDIg8kFzyhQ== X-Received: by 2002:a17:902:6803:: with SMTP id h3mr14323490plk.319.1575648124842; Fri, 06 Dec 2019 08:02:04 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id i4sm3867272pjw.28.2019.12.06.08.02.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 08:02:03 -0800 (PST) From: Ted Lemon Message-Id: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_52BD073E-5C44-4C97-A606-9A4489660E12" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Fri, 6 Dec 2019 08:02:02 -0800 In-Reply-To: Cc: Philip Homburg , "v6ops@ietf.org" , "dhcwg@ietf.org" To: "Bernie Volz (volz)" References: X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 16:02:08 -0000 --Apple-Mail=_52BD073E-5C44-4C97-A606-9A4489660E12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) wrote: > which requires fewer changes on the DHCP server implementation This is almost certainly not true. In order for this to work, you=E2=80=99= re going to have to have some special-purpose code to support it. = Better to do the clean solution than a hack that minimizes changes to = the server at the expense of more complication in the client-server = interaction. > Existing servers can deploy this without ANY changes (provided you = have a means to configure the server with whatever option number is = finally assigned). I think it=E2=80=99s okay to require changes to the server. This is a = significant new feature. > Personally, I would NOT recommend breaking the semantics of a = DHCPOFFER and always include an address because you never know how = intermediate devices that may be "snooping" this traffic will handle = this; for example, the intermediate device might drop what it feels is = an invalid packet. This is definitely not an issue, though, because the network operator is = choosing to deploy this. They can be responsible for ensuring correct = behavior if there are any middleboxes intercepting the DHCPv4 traffic = and doing stuff with it. Expecting this to Just Work with no = infrastructure changes seems unnecessary. >> There is a reason why DHCP includes a parameter request list option. = If the client doesn=E2=80=99t ask for this newfangled option, it = shouldn=E2=80=99t see it. And so we can know for sure that the client = supports this capability, because it asked for it. >=20 > Even if a DHCP server sent the option without it being requested, why = would the client use it if it didn't ask for it? If the DHCP server knows the client supports the feature, it can assume = that when it sends the option, the client will implement the specified = behavior. If it doesn=E2=80=99t know for sure that the client supports = the feature, then you have to deal with a much more complex set of = possible behaviors. Why add that complexity? And that=E2=80=99s assuming that the client behaves correctly. If you = just send the new option, another possibility is that the client crashes = when it doesn=E2=80=99t recognize the option, as we used to see with = certain printers I the manufacturer of which I will not mention. Or = that it does some other random thing. Why chance it? --Apple-Mail=_52BD073E-5C44-4C97-A606-9A4489660E12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
which = requires fewer changes on the DHCP server = implementation

This is almost certainly not true.  In order for this to = work, you=E2=80=99re going to have to have some special-purpose code to = support it.  Better to do the clean solution than a hack that = minimizes changes to the server at the expense of more complication in = the client-server interaction.

Existing servers can deploy = this without ANY changes (provided you have a means to configure the = server with whatever option number is finally = assigned).

I = think it=E2=80=99s okay to require changes to the server.   This is = a significant new feature.

Personally, I would NOT recommend breaking = the semantics of a DHCPOFFER and always include an address because you = never know how intermediate devices that may be "snooping" this traffic = will handle this; for example, the intermediate device might drop what = it feels is an invalid packet.

This is definitely not an issue, = though, because the network operator is choosing to deploy this. =  They can be responsible for ensuring correct behavior if there are = any middleboxes intercepting the DHCPv4 traffic and doing stuff with it. =   Expecting this to Just Work with no infrastructure changes seems = unnecessary.

There is a reason why = DHCP includes a parameter request list option.  If the client = doesn=E2=80=99t ask for this newfangled option, it shouldn=E2=80=99t see = it.  And so we can know for sure that the client supports this = capability, because it asked for it.

Even if a = DHCP server sent the option without it being requested, why would the = client use it if it didn't ask for it?

If the DHCP server knows the client = supports the feature, it can assume that when it sends the option, the = client will implement the specified behavior.   If it doesn=E2=80=99t= know for sure that the client supports the feature, then you have to = deal with a much more complex set of possible behaviors.   Why add = that complexity?

And that=E2=80=99s assuming that the client behaves correctly.  If you just send the new option, another = possibility is that the client crashes when it doesn=E2=80=99t recognize = the option, as we used to see with certain printers I the manufacturer = of which I will not mention.   Or that it does some other random = thing.  Why chance it?


= --Apple-Mail=_52BD073E-5C44-4C97-A606-9A4489660E12-- From nobody Fri Dec 6 08:02:47 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6902A120807 for ; Fri, 6 Dec 2019 08:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pfNeYX_GMCRV for ; Fri, 6 Dec 2019 08:02:38 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C51120850 for ; Fri, 6 Dec 2019 08:02:37 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id y14so3531111pfm.13 for ; Fri, 06 Dec 2019 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cTUKUYvjdAXoF9uQGUhZQx1GzrtgFNt/YSFxSUbCijA=; b=oCl8cAQWthqxcBhDv7Ih3uMkW+piFTY2HcTCiRyL64tNY2ys4o6L5NssI+Enf3AgC2 UpWWWvMCnLB6wErsBn3IrjqtyStjwCq03BB2Y1ZVAIPmwUatLCvx+iHZoRmYd5tAClW3 WpQ3tPb/sVHovHI9tL/3IQI6cwRG+42YVFdSX4AciKCMBUHKvCi5rNWjJdOqeR/DhbVu ytTWAExXjV2f3T4tfpDuEqkpn9qOsXVfzvdDd0QlQ/t7KPJjE5GGs0inLkXJblAJgSmE DjlIfBTotDJeduVmSvowT6jkU0KElRSVLqIJiU416OulRwP1DD9SHlV1YsSndHa6OiiO RJog== 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=cTUKUYvjdAXoF9uQGUhZQx1GzrtgFNt/YSFxSUbCijA=; b=itbb+Otkw8be39Xi8bgoxpJanJgXbOLUgRqUUIpLH7UVHJofsySVsbEFI4WqNpJy9y zKDt8Zqop8r6MZf/n89KLYYXdrVrT6VYaq0913VXk/O1GjEOFpXytdGvDkASYy1Y1s1S 3/NxV55OpVPVhm1/X69cASilBMvOW0Q52ntxa9mdOKc8K72F87sEcSTt5tzKseZWcoYW OfwYPwC2gE5QwCJu4IgWYc2oAzaCVz/Ae3UTYU3XbnmNizSR7WK4I++IhDB0w9XPWsIB pTvt7JYffl2VIHem5tm0njxyxbMEkl8kwoleGOVG5xe66BA1ehl9Ic9HEfwYzrOK94+m aRAQ== X-Gm-Message-State: APjAAAXkjUg6jvdWjEhYYQDjKF4jbmIzPk4+wGyD0bENC9L4WochGmge 65zGH1mHVeYQEhIdKGE/UbMEEw== X-Google-Smtp-Source: APXvYqx1i+cVvXDwPNawOom/XBVMuqgbNwlQHepBM5XeistRj4RrvmS+4PxmSOwT3PwbLA5djfxRtQ== X-Received: by 2002:a63:de08:: with SMTP id f8mr4221138pgg.107.1575648157362; Fri, 06 Dec 2019 08:02:37 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id i4sm3867272pjw.28.2019.12.06.08.02.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 08:02:36 -0800 (PST) From: Ted Lemon Message-Id: <3E4E9BD1-36C4-4096-8B34-F6C39FC781A8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A67D34D-A359-4878-993B-41C3239F5A5D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Fri, 6 Dec 2019 08:02:35 -0800 In-Reply-To: <5391.1575645940@localhost> Cc: Jen Linkova , V6 Ops List , draft-link-dhc-v6only@ietf.org, dhcwg@ietf.org To: Michael Richardson References: <28594.1575483729@localhost> <5391.1575645940@localhost> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 16:02:41 -0000 --Apple-Mail=_2A67D34D-A359-4878-993B-41C3239F5A5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 6, 2019, at 7:25 AM, Michael Richardson = wrote: > The goal is not to assign an address, but ciaddr is a fixed field, so = we have > to put something in, and I think that we are worried that 0.0.0.0 is = going to > confuse DHCP relay nodes that snoop. ciaddr is 0.0.0.0 in a DHCPOFFER, right? --Apple-Mail=_2A67D34D-A359-4878-993B-41C3239F5A5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 6, 2019, at 7:25 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
The goal is not to assign an address, but ciaddr is a fixed = field, so we have
to put something in, and I think that we are worried that = 0.0.0.0 is going to
confuse DHCP relay nodes that = snoop.

ciaddr is 0.0.0.0 in a DHCPOFFER, right?

= --Apple-Mail=_2A67D34D-A359-4878-993B-41C3239F5A5D-- From nobody Fri Dec 6 08:18:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E16120843; Fri, 6 Dec 2019 08:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=D2pWAgxz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=G+5PgWf0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9SbeS7haH_n; Fri, 6 Dec 2019 08:18:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AFC12083D; Fri, 6 Dec 2019 08:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24809; q=dns/txt; s=iport; t=1575649118; x=1576858718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h3q4/gP/eAfcoBjZuTEWY9UEqRYK3A1eaa3GZSaA8ok=; b=D2pWAgxzQ8cYgsOhNNTC9/vXy2oWeQ4/8RuS1S+GGNNo7Mk/VBL/kkaQ iiA3JHS2Btx/bjkw5s77ckCZbFXc0P6VimrxtAY0qWnxOxhLpyUMAyfls hl0DmA1z0MkODt9BaarBFwIYyflz2osjqbfmQrGLoAGhc+Bo330HCVJv+ I=; IronPort-PHdr: =?us-ascii?q?9a23=3ApkNPAhLE/uhWrpIDqdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAAAqf+pd/4wNJK1eBhwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYFsBQEBCwGBGy8pJwVsWCAECyoKhCGDRgOKf4I6JZMihGKBLoE?= =?us-ascii?q?kA1QJAQEBDAEBLQIBAYRAAheBfiQ2Bw4CAw0BAQQBAQECAQUEbYU3DIVSAQE?= =?us-ascii?q?BAQMSER0BATcBDwIBCA4DAwECKAMCAgIwFAkIAgQOBRsHgwABgXlNAy4BAqJ?= =?us-ascii?q?LAoE4iGB1gTKCfgEBBYUTGIIXCYE2AYwWGoIAgTgMFIFOfj6EMwguFoJaMoI?= =?us-ascii?q?sjSgIGhmCPoVPgj+VL3AKgi6MRokUG5omqG0CBAIEBQIOAQEFgVkCMIFYcBU?= =?us-ascii?q?7KgGCQVARFIxmB4EgAQmCQopTdIEojX8HI4EHATBfAQE?= X-IronPort-AV: E=Sophos;i="5.69,285,1571702400"; d="scan'208,217";a="678347160" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 16:18:31 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6GIVC1020581 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 16:18:31 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 10:18:30 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 11:18:29 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 11:18:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+h8ss5BDpq7It0j0y8dmTtOR9pdi69GCUnFAAyn622ZhPHPvfzxE/JB7uqU8N+BQffZ55nYB7rH17ggTl/e+j5PAGz8wHMh6yGHgu5KZAJstDtdSxMEOE5i7p89dXTkCJFQj29y1McYz3vTMKz0SiH7U15NWhHKjO0eEZZl6TGFH2XunXLfZgu4qIWhmEDykcKvjoFuOOtGK3Pg+MxdQVI2qVPf56E3aIDjyOcOHvgGbO+9svflrnB4zrgXiBiziW/aJqHoLOUE66m8J5IHAarT8U7nbkCg0NLjY7F2gJwWHiAoEPwLySpYSwblDaC5N/6WDdNpNybXxjO71ic8hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h3q4/gP/eAfcoBjZuTEWY9UEqRYK3A1eaa3GZSaA8ok=; b=IebFLsJCR9x3SowWKyGlI8qOuscYHTVBHNwbmCUlR/Ckd/53DdLwQbHMb8NbwYg7p7dprvhe63SAiJl/XEIY/c+RQ8gUVz67w3HAI3Y21f8g/aZlLpMHgKc+9xOD0tk65kW4uoas5LtPTtDDOR78MDMYthrZ1W9wqP6sLI7gJhNKXrhTJ3wrMYUn8srWRsG7KG/1Z4pmEaUmBo9/bGeRB2on9AFfeDKsMn5m/fSpXsMuonYKOBC8ufrJXSY1zrmC7F8x8OqU4rEzOETA7Uqd8yBbcS6XcCKPOJF0FpLzLhx2MEDpYSf9+zE5D5VVtHe9A/MuLbUaj9thoXtNlk6ZBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h3q4/gP/eAfcoBjZuTEWY9UEqRYK3A1eaa3GZSaA8ok=; b=G+5PgWf0oDi/RqiDgHHqJTEnAVsNKPuZRFLqWRk8cVXl7kewndZP0OHG5wnZaEJHC/PhOo4CGWwWTn/L2h2xNuaYwzBEPtItg9e4+yEjkCT6mFE99uPGUGA23aZuRDAb3J9EtGLOV2iNWJ6rn9LqGZ137QZlruxc0Yi+t/ZE+6U= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4188.namprd11.prod.outlook.com (20.176.126.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Fri, 6 Dec 2019 16:18:29 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 16:18:29 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Philip Homburg , "v6ops@ietf.org" , "dhcwg@ietf.org" Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrEHbgQve9DKh2EKQEqgwr7Y10qetK3KQgAAZCAD//7DFgA== Date: Fri, 6 Dec 2019 16:18:28 +0000 Message-ID: <1D8C9B8A-0F46-4B02-9402-2265F86D5F0F@cisco.com> References: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> In-Reply-To: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aad6f863-9430-4daa-1407-08d77a67ee0b x-ms-traffictypediagnostic: DM6PR11MB4188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(136003)(376002)(39860400002)(189003)(199004)(36756003)(54896002)(2616005)(478600001)(229853002)(6486002)(66476007)(66946007)(2906002)(66556008)(91956017)(66446008)(64756008)(6916009)(76116006)(76176011)(26005)(99286004)(186003)(8936002)(71190400001)(71200400001)(5660300002)(81156014)(81166006)(8676002)(6506007)(53546011)(102836004)(316002)(58126008)(6512007)(86362001)(33656002)(4326008)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4188; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rGX7h5YOSU6MLN4PubIzv8hysl62uWvyV3g5SakoIzWAzKsKaSBy/Otm2sYx+tso2qgkQaFXuS55fuhn+lTQE8amJ2J7+csCr3fkrGkH//V0tVCxy6C+v8NQkKxYDwNRA2rEXKD2Lh2L8YsJEEBQUy+zJ/fRSty90qfLmYVfRtPhR7NLKQLL1RxD27qXyEh+zkrxm+JLPV+Vdu+DpmMQvuIKxx4l9III5tsv0wgNMhRdq3unDFb+tw4DOJBuDIhQvsKzRtoDwE4FDbehItZmV46BhZmPxmjmAKnleIpTycw08hV+zegiXWOsR3rG0kg7JCMKsZ+z6BsqlaEcqr1uE8UoP7apm+JyLbFg1PObfts+OWcUg7zYR/NL6k7JKeW1MoAVO775b9A300FkHyIuU60tRbJ+9prBYlV/bEtlURnSRTSvSWR5DU2A3hs0Y0A+ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1D8C9B8A0F464B0294022265F86D5F0Fciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aad6f863-9430-4daa-1407-08d77a67ee0b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 16:18:28.6929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r8sd1ublT2IRfyil3hxePu+zbhBb/0FYv9TGYXXysWqdfgKJhLXGVHQVa9bv6aGU X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4188 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 16:18:41 -0000 --_000_1D8C9B8A0F464B0294022265F86D5F0Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW5saW5lIGJlbG93IChCVj4pLg0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9tOiBU ZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpEYXRlOiBGcmlkYXksIERlY2VtYmVyIDYsIDIw MTkgYXQgMTE6MDIgQU0NClRvOiBCZXJuaWUgVm9seiA8dm9sekBjaXNjby5jb20+DQpDYzogUGhp bGlwIEhvbWJ1cmcgPHBjaC12Nm9wcy05QHUtMS5waGljb2guY29tPiwgInY2b3BzQGlldGYub3Jn IiA8djZvcHNAaWV0Zi5vcmc+LCAiZGhjd2dAaWV0Zi5vcmciIDxkaGN3Z0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYtT25seSBQcmVmZXJyZWQgREhDUHY0IG9wdGlvbg0KDQpP biBEZWMgNiwgMjAxOSwgYXQgNjo0NSBBTSwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2Nv LmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCndoaWNoIHJlcXVpcmVzIGZld2Vy IGNoYW5nZXMgb24gdGhlIERIQ1Agc2VydmVyIGltcGxlbWVudGF0aW9uDQoNClRoaXMgaXMgYWxt b3N0IGNlcnRhaW5seSBub3QgdHJ1ZS4gIEluIG9yZGVyIGZvciB0aGlzIHRvIHdvcmssIHlvdeKA mXJlIGdvaW5nIHRvIGhhdmUgdG8gaGF2ZSBzb21lIHNwZWNpYWwtcHVycG9zZSBjb2RlIHRvIHN1 cHBvcnQgaXQuICBCZXR0ZXIgdG8gZG8gdGhlIGNsZWFuIHNvbHV0aW9uIHRoYW4gYSBoYWNrIHRo YXQgbWluaW1pemVzIGNoYW5nZXMgdG8gdGhlIHNlcnZlciBhdCB0aGUgZXhwZW5zZSBvZiBtb3Jl IGNvbXBsaWNhdGlvbiBpbiB0aGUgY2xpZW50LXNlcnZlciBpbnRlcmFjdGlvbi4NCg0KQlY+IFdo eSBhcmUgYW55IGNoYW5nZXMgbmVlZGVkIHRvIHRoZSBzZXJ2ZXI/IEl04oCZcyBub3JtYWwgcHJv Y2Vzc2luZyB3aWxsIHdvcmsganVzdCBmaW5lIOKApiBpZiB0aGUgbmV0d29yayBzZWdtZW50IGhh cyB0aGUgbmV3IG9wdGlvbiBjb25maWd1cmVkLCBpdCB3aWxsIHJldHVybiBpdCBpZiB0aGUgY2xp ZW50IHJlcXVlc3RzIGl0LiBUaGVuIHRoZSBzZXJ2ZXIgd2lsbCBuZXZlciBzZWUgdGhlIERIQ1BS RVFVRVNUIGFuZCB0aGUgYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUgY2xpZW50IHdpbGwganVzdCDi gJx0aW1lb3V04oCdIGluIGEgc2hvcnQgcGVyaW9kIChhdCBsZWFzdCBvbiBvdXIgc2VydmVyLCB3 aXRoaW4gMiBtaW51dGVzIG9yIHdoYXRldmVyIGFuIGFkbWluaXN0cmF0b3IgaGFzIGNvbmZpZ3Vy ZWQpIGFuZCBiZSB1c2FibGUgYnkgb3RoZXIgY2xpZW50cy4gRW5kIG9mIHN0b3J5IGFzIGNsaWVu dCBoYXMgdHVybmVkIG9mZiBESENQdjQgYW5kIGV2ZXJ5b25lIGlzIGhhcHB5LiBBbmQsIG5vIGNo YW5nZXMgdG8gYW55dGhpbmcgb24gdGhlIHNlcnZlci4gVGhpcyBpcyBub3QgZGlmZmVyZW50IHRo YW4gYSBjYXNlIHdoZXJlIHRoZXJlIHRoZSBjbGllbnQgbmV2ZXIgc2VuZHMgYSBESENQUkVRVUVT VCBvciBzZWxlY3RzIGEgREhDUFJFUVVFU1QgZnJvbSBhIGRpZmZlcmVudCBzZXJ2ZXIuDQoNCkJW PiBJZiB0aGUgY2xpZW50IGRvZXMgcHJvY2VlZCB0byBhIERIQ1BSRVFVRVNULCBub3JtYWwgcHJv Y2Vzc2luZyB3b3VsZCBoYXBwZW4sIGFuZCBjbGllbnQgd291bGQgZ2V0IHRoZSBsZWFzZSAob3Ig cGVyaGFwcyByZWNlaXZlIGEgREhDUE5BSyBpcyBzb21lIG90aGVyIGRldmljZSB3YXMgYXNzaWdu ZWQgdGhlIGxlYXNlIGJlY2F1c2UgdGhlIHNob3J0IHRpbWUgaXQgaGFkIGJlZW4gaGVsZCBleHBp cmVkKS4NCg0KQlY+IFRoaXMgaXMgYWxsIG5vcm1hbCBESENQdjQgcHJvY2Vzc2luZyBhbmQgc28g bm8gY2hhbmdlcyBhcmUgbmVlZGVkLg0KDQpFeGlzdGluZyBzZXJ2ZXJzIGNhbiBkZXBsb3kgdGhp cyB3aXRob3V0IEFOWSBjaGFuZ2VzIChwcm92aWRlZCB5b3UgaGF2ZSBhIG1lYW5zIHRvIGNvbmZp Z3VyZSB0aGUgc2VydmVyIHdpdGggd2hhdGV2ZXIgb3B0aW9uIG51bWJlciBpcyBmaW5hbGx5IGFz c2lnbmVkKS4NCg0KSSB0aGluayBpdOKAmXMgb2theSB0byByZXF1aXJlIGNoYW5nZXMgdG8gdGhl IHNlcnZlci4gICBUaGlzIGlzIGEgc2lnbmlmaWNhbnQgbmV3IGZlYXR1cmUuDQoNCkJWPiBXaHkg dGhlcmUgaXMgbm8gbmVlZD8gWWVzLCB5b3UgY291bGQgZG8gb3B0aW1pemF0aW9ucyB0byAoMSkg aGF2ZSBwZXJoYXBzIGEgbXVjaCBzaG9ydGVyIHRlbXBvcmFyeSBhc3NpZ25tZW50IHRpbWUgb3Ig KDIpIHVzZSBhIOKAnHJlc2VydmVk4oCdIGFkZHJlc3MgZm9yIGNsaWVudHMgdGhhdCByZXF1ZXN0 IHRoaXMgb3B0aW9uIGluIHRoZSBQUkwuIEJ1dCB0aGVzZSBhcmUgbm90IG5lY2Vzc2FyeSwgYW5k IGV2ZXJ5dGhpbmcgd29ya3MganVzdCBmaW5lIHdpdGhvdXQgdGhlIGNoYW5nZXMuDQoNClBlcnNv bmFsbHksIEkgd291bGQgTk9UIHJlY29tbWVuZCBicmVha2luZyB0aGUgc2VtYW50aWNzIG9mIGEg REhDUE9GRkVSIGFuZCBhbHdheXMgaW5jbHVkZSBhbiBhZGRyZXNzIGJlY2F1c2UgeW91IG5ldmVy IGtub3cgaG93IGludGVybWVkaWF0ZSBkZXZpY2VzIHRoYXQgbWF5IGJlICJzbm9vcGluZyIgdGhp cyB0cmFmZmljIHdpbGwgaGFuZGxlIHRoaXM7IGZvciBleGFtcGxlLCB0aGUgaW50ZXJtZWRpYXRl IGRldmljZSBtaWdodCBkcm9wIHdoYXQgaXQgZmVlbHMgaXMgYW4gaW52YWxpZCBwYWNrZXQuDQoN ClRoaXMgaXMgZGVmaW5pdGVseSBub3QgYW4gaXNzdWUsIHRob3VnaCwgYmVjYXVzZSB0aGUgbmV0 d29yayBvcGVyYXRvciBpcyBjaG9vc2luZyB0byBkZXBsb3kgdGhpcy4gIFRoZXkgY2FuIGJlIHJl c3BvbnNpYmxlIGZvciBlbnN1cmluZyBjb3JyZWN0IGJlaGF2aW9yIGlmIHRoZXJlIGFyZSBhbnkg bWlkZGxlYm94ZXMgaW50ZXJjZXB0aW5nIHRoZSBESENQdjQgdHJhZmZpYyBhbmQgZG9pbmcgc3R1 ZmYgd2l0aCBpdC4gICBFeHBlY3RpbmcgdGhpcyB0byBKdXN0IFdvcmsgd2l0aCBubyBpbmZyYXN0 cnVjdHVyZSBjaGFuZ2VzIHNlZW1zIHVubmVjZXNzYXJ5Lg0KDQpCVj4gV2h5IG5lZWQgdGhpcyB0 ZXN0aW5nIHRvIGNvbmZpcm0gdGhhdCBtaWRkbGVib3hlcyBhcmVu4oCZdCBkb2luZyBiYWQgc3R1 ZmYuIElmIHlvdSBzdGljayB0byBub3JtYWwgREhDUCBzZW1hbnRpY3MsIG5vdGhpbmcgbmVlZHMg dG8gYmUgdGVzdGVkIG9yIGNoYW5nZWQgaW4geW91ciBpbmZyYXN0cnVjdHVyZS4gWWVzLCBJIGFt IGV4cGVjdGluZyB0aGlzIHRvIHdvcmsgd2l0aCBubyBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzIGFz IHRoaXMgaXMgU1RBTkRBUkQgREhDUC4gVGhlIERIQ1BPRkZFUiBqdXN0IG5ldmVyIHR1cm5zIGlu IHRvIGEgREhDUFJFUVVFU1Qg4oCTIHNvIHdoYXQg4oCmIHRoaXMgY2FuIGhhcHBlbiB0b2RheSBv biBhbGwgREhDUCBuZXR3b3JrcyBpZiB0aGUgY2xpZW50IHN0b3BzIChwb3dlcmVkIGRvd24sIGRp c2Nvbm5lY3RzIGZyb20gbmV0d29yaykuDQoNClRoZXJlIGlzIGEgcmVhc29uIHdoeSBESENQIGlu Y2x1ZGVzIGEgcGFyYW1ldGVyIHJlcXVlc3QgbGlzdCBvcHRpb24uICBJZiB0aGUgY2xpZW50IGRv ZXNu4oCZdCBhc2sgZm9yIHRoaXMgbmV3ZmFuZ2xlZCBvcHRpb24sIGl0IHNob3VsZG7igJl0IHNl ZSBpdC4gIEFuZCBzbyB3ZSBjYW4ga25vdyBmb3Igc3VyZSB0aGF0IHRoZSBjbGllbnQgc3VwcG9y dHMgdGhpcyBjYXBhYmlsaXR5LCBiZWNhdXNlIGl0IGFza2VkIGZvciBpdC4NCg0KRXZlbiBpZiBh IERIQ1Agc2VydmVyIHNlbnQgdGhlIG9wdGlvbiB3aXRob3V0IGl0IGJlaW5nIHJlcXVlc3RlZCwg d2h5IHdvdWxkIHRoZSBjbGllbnQgdXNlIGl0IGlmIGl0IGRpZG4ndCBhc2sgZm9yIGl0Pw0KDQpJ ZiB0aGUgREhDUCBzZXJ2ZXIga25vd3MgdGhlIGNsaWVudCBzdXBwb3J0cyB0aGUgZmVhdHVyZSwg aXQgY2FuIGFzc3VtZSB0aGF0IHdoZW4gaXQgc2VuZHMgdGhlIG9wdGlvbiwgdGhlIGNsaWVudCB3 aWxsIGltcGxlbWVudCB0aGUgc3BlY2lmaWVkIGJlaGF2aW9yLiAgIElmIGl0IGRvZXNu4oCZdCBr bm93IGZvciBzdXJlIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0aGUgZmVhdHVyZSwgdGhlbiB5 b3UgaGF2ZSB0byBkZWFsIHdpdGggYSBtdWNoIG1vcmUgY29tcGxleCBzZXQgb2YgcG9zc2libGUg YmVoYXZpb3JzLiAgIFdoeSBhZGQgdGhhdCBjb21wbGV4aXR5Pw0KDQpBbmQgdGhhdOKAmXMgYXNz dW1pbmcgdGhhdCB0aGUgY2xpZW50IGJlaGF2ZXMgY29ycmVjdGx5LiAgSWYgeW91IGp1c3Qgc2Vu ZCB0aGUgbmV3IG9wdGlvbiwgYW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0aGF0IHRoZSBjbGllbnQg Y3Jhc2hlcyB3aGVuIGl0IGRvZXNu4oCZdCByZWNvZ25pemUgdGhlIG9wdGlvbiwgYXMgd2UgdXNl ZCB0byBzZWUgd2l0aCBjZXJ0YWluIHByaW50ZXJzIEkgdGhlIG1hbnVmYWN0dXJlciBvZiB3aGlj aCBJIHdpbGwgbm90IG1lbnRpb24uICAgT3IgdGhhdCBpdCBkb2VzIHNvbWUgb3RoZXIgcmFuZG9t IHRoaW5nLiAgV2h5IGNoYW5jZSBpdD8NCg0KQlY+IElmIGEgREhDUCBjbGllbnQgY3Jhc2hlcyB3 aGVuIGl0IHJlY2VpdmVzIGFuIHVua25vd24gb3B0aW9uLCBteSBndWVzcyBpcyB0aGF0IGl0IHdv dWxkIGJlIHF1aWNrbHkgZml4ZWQgYXMgdGhpcyBqdXN0IGlzIGJyb2tlbiBiZWhhdmlvci4gQWdh aW4sIEnigJltIG5vdCBzYXlpbmcgdGhhdCBhIHNlcnZlciBzaG91bGQgc2VuZCB0aGlzIG9wdGlv biBpZiBpdCB3YXNu4oCZdCByZXF1ZXN0ZWQgYnkgYSBjbGllbnQsIGJ1dCBJ4oCZbSBqdXN0IGNs YXJpZnlpbmcgeW91ciBzdGF0ZW1lbnRzIHRoYXQgZXZlbiBpZiBhIGNsaWVudCB3ZXJlIHRvIHNl ZSBzb21lIGFyYml0cmFyeSBvcHRpb24gdGhhdCBpdCBkaWRu4oCZdCByZXF1ZXN0LCBpdCBzaG91 bGRu4oCZdCBiZSBkb2luZyBhbnl0aGluZyB3aXRoIGl0LiBBbmQsIEkgd291bGQgc3VzcGVjdCB0 aGF0IHlvdSB3b3VsZCBiZSBoYXJkIHByZXNzZWQgdG8gZmluZCBhIGNsaWVudCB0aGF0IGNyYXNo ZXMgd2hlbiBpdCByZWNlaXZlcyBhbiB1bmtub3duIG9wdGlvbi4NCg0KQlY+IEkgd2lsbCBzYXkg dGhhdCBvbmUgaXNzdWUgdGhhdCBjb3VsZCBleGlzdCB3aXRoIHRoaXMgb3B0aW9uIHRoYXQgaXMg YSBiaXQgdW51c3VhbCBpcyB0aGF0IGl0IGlzIGN1cnJlbnRseSAwLWxlbmd0aC4gV2UgaGF2ZSBv bmx5IG9uZSBvdGhlciB6ZXJvLWxlbmd0aCBvcHRpb24gdGhhdCBJIHJlY2FsbCwgYW5kIHRoYXQg aXMgUmFwaWQgQ29tbWl0ICh3aGljaCBpcyBjbGllbnQgdG8gc2VydmVyLCBub3Qgc2VydmVyIHRv IGNsaWVudCkuIFNvLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHRoZXJlIGFyZSBjbGllbnRzIHRoYXQg YXJlIHVuaGFwcHkgYWJvdXQgemVyby1sZW5ndGggb3B0aW9ucy4gQnV0IGFnYWluLCBpbiB0aGUg aWRlYWwgd29ybGQgbm8gY2xpZW50IHdpbGwgc2VlIHRoaXMgb3B0aW9uIHVubGVzcyBpdCBoYXMg cmVxdWVzdGVkIGl0IChpbiB0aGUgUFJMKS4NCg0KDQo= --_000_1D8C9B8A0F464B0294022265F86D5F0Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BEAFEF1D9E46442B8874782F70504C7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6TWVubG8tUmVndWxhcjsNCglwYW5vc2UtMToyIDExIDYgOSAzIDggNCAyIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTkwNTk1 NzM0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODU1 MDk1NjU4IDk1NjA4MTYzNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHMgaW5saW5l IGJlbG93IChCViZndDspLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QmVybmllPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UZWQgTGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgRGVjZW1iZXIgNiwgMjAxOSBhdCAxMTowMiBBTTxi cj4NCjxiPlRvOiA8L2I+QmVybmllIFZvbHogJmx0O3ZvbHpAY2lzY28uY29tJmd0Ozxicj4NCjxi PkNjOiA8L2I+UGhpbGlwIEhvbWJ1cmcgJmx0O3BjaC12Nm9wcy05QHUtMS5waGljb2guY29tJmd0 OywgJnF1b3Q7djZvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Y2b3BzQGlldGYub3JnJmd0OywgJnF1 b3Q7ZGhjd2dAaWV0Zi5vcmcmcXVvdDsgJmx0O2RoY3dnQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW3Y2b3BzXSBJUHY2LU9ubHkgUHJlZmVycmVkIERIQ1B2NCBvcHRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RGVjIDYsIDIwMTksIGF0IDY6NDUgQU0sIEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnZvbHpAY2lzY28uY29tIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZx dW90OyxzZXJpZiI+d2hpY2ggcmVxdWlyZXMgZmV3ZXIgY2hhbmdlcyBvbiB0aGUgREhDUCBzZXJ2 ZXIgaW1wbGVtZW50YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhbG1vc3QgY2VydGFpbmx5IG5v dCB0cnVlLiAmbmJzcDtJbiBvcmRlciBmb3IgdGhpcyB0byB3b3JrLCB5b3XigJlyZSBnb2luZyB0 byBoYXZlIHRvIGhhdmUgc29tZSBzcGVjaWFsLXB1cnBvc2UgY29kZSB0byBzdXBwb3J0IGl0LiAm bmJzcDtCZXR0ZXIgdG8gZG8gdGhlIGNsZWFuIHNvbHV0aW9uIHRoYW4gYSBoYWNrIHRoYXQgbWlu aW1pemVzIGNoYW5nZXMgdG8gdGhlIHNlcnZlciBhdCB0aGUgZXhwZW5zZSBvZiBtb3JlDQogY29t cGxpY2F0aW9uIGluIHRoZSBjbGllbnQtc2VydmVyIGludGVyYWN0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CViZndDsgV2h5IGFyZSBhbnkgY2hhbmdlcyBuZWVk ZWQgdG8gdGhlIHNlcnZlcj8gSXTigJlzIG5vcm1hbCBwcm9jZXNzaW5nIHdpbGwgd29yayBqdXN0 IGZpbmUg4oCmIGlmIHRoZSBuZXR3b3JrIHNlZ21lbnQgaGFzIHRoZSBuZXcgb3B0aW9uIGNvbmZp Z3VyZWQsIGl0IHdpbGwgcmV0dXJuIGl0IGlmIHRoZSBjbGllbnQgcmVxdWVzdHMgaXQuIFRoZW4g dGhlIHNlcnZlciB3aWxsIG5ldmVyIHNlZSB0aGUgREhDUFJFUVVFU1QNCiBhbmQgdGhlIGFkZHJl c3MgYXNzaWduZWQgdG8gdGhlIGNsaWVudCB3aWxsIGp1c3Qg4oCcdGltZW91dOKAnSBpbiBhIHNo b3J0IHBlcmlvZCAoYXQgbGVhc3Qgb24gb3VyIHNlcnZlciwgd2l0aGluIDIgbWludXRlcyBvciB3 aGF0ZXZlciBhbiBhZG1pbmlzdHJhdG9yIGhhcyBjb25maWd1cmVkKSBhbmQgYmUgdXNhYmxlIGJ5 IG90aGVyIGNsaWVudHMuIEVuZCBvZiBzdG9yeSBhcyBjbGllbnQgaGFzIHR1cm5lZCBvZmYgREhD UHY0IGFuZCBldmVyeW9uZSBpcw0KIGhhcHB5LiBBbmQsIG5vIGNoYW5nZXMgdG8gYW55dGhpbmcg b24gdGhlIHNlcnZlci4gVGhpcyBpcyBub3QgZGlmZmVyZW50IHRoYW4gYSBjYXNlIHdoZXJlIHRo ZXJlIHRoZSBjbGllbnQgbmV2ZXIgc2VuZHMgYSBESENQUkVRVUVTVCBvciBzZWxlY3RzIGEgREhD UFJFUVVFU1QgZnJvbSBhIGRpZmZlcmVudCBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJWJmd0OyBJZiB0aGUgY2xpZW50IGRvZXMgcHJvY2VlZCB0byBhIERIQ1BSRVFVRVNULCBub3Jt YWwgcHJvY2Vzc2luZyB3b3VsZCBoYXBwZW4sIGFuZCBjbGllbnQgd291bGQgZ2V0IHRoZSBsZWFz ZSAob3IgcGVyaGFwcyByZWNlaXZlIGEgREhDUE5BSyBpcyBzb21lIG90aGVyIGRldmljZSB3YXMg YXNzaWduZWQgdGhlIGxlYXNlIGJlY2F1c2UgdGhlIHNob3J0IHRpbWUgaXQgaGFkIGJlZW4gaGVs ZCBleHBpcmVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlYmZ3Q7IFRoaXMgaXMgYWxsIG5v cm1hbCBESENQdjQgcHJvY2Vzc2luZyBhbmQgc28gbm8gY2hhbmdlcyBhcmUgbmVlZGVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5FeGlzdGlu ZyBzZXJ2ZXJzIGNhbiBkZXBsb3kgdGhpcyB3aXRob3V0IEFOWSBjaGFuZ2VzIChwcm92aWRlZCB5 b3UgaGF2ZSBhIG1lYW5zIHRvIGNvbmZpZ3VyZSB0aGUgc2VydmVyIHdpdGggd2hhdGV2ZXIgb3B0 aW9uIG51bWJlciBpcyBmaW5hbGx5IGFzc2lnbmVkKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXTigJlzIG9rYXkg dG8gcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBzZXJ2ZXIuICZuYnNwOyBUaGlzIGlzIGEgc2lnbmlm aWNhbnQgbmV3IGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJWJmd0OyBXaHkgdGhl cmUgaXMgbm8gbmVlZD8gWWVzLCB5b3UgY291bGQgZG8gb3B0aW1pemF0aW9ucyB0byAoMSkgaGF2 ZSBwZXJoYXBzIGEgbXVjaCBzaG9ydGVyIHRlbXBvcmFyeSBhc3NpZ25tZW50IHRpbWUgb3IgKDIp IHVzZSBhIOKAnHJlc2VydmVk4oCdIGFkZHJlc3MgZm9yIGNsaWVudHMgdGhhdCByZXF1ZXN0IHRo aXMgb3B0aW9uIGluIHRoZSBQUkwuIEJ1dCB0aGVzZSBhcmUgbm90IG5lY2Vzc2FyeSwgYW5kIGV2 ZXJ5dGhpbmcNCiB3b3JrcyBqdXN0IGZpbmUgd2l0aG91dCB0aGUgY2hhbmdlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+UGVyc29uYWxseSwgSSB3b3VsZCBOT1QgcmVjb21tZW5kIGJyZWFraW5nIHRoZSBzZW1hbnRp Y3Mgb2YgYSBESENQT0ZGRVIgYW5kIGFsd2F5cyBpbmNsdWRlIGFuIGFkZHJlc3MgYmVjYXVzZSB5 b3UgbmV2ZXIga25vdyBob3cgaW50ZXJtZWRpYXRlIGRldmljZXMgdGhhdCBtYXkgYmUgJnF1b3Q7 c25vb3BpbmcmcXVvdDsgdGhpcw0KIHRyYWZmaWMgd2lsbCBoYW5kbGUgdGhpczsgZm9yIGV4YW1w bGUsIHRoZSBpbnRlcm1lZGlhdGUgZGV2aWNlIG1pZ2h0IGRyb3Agd2hhdCBpdCBmZWVscyBpcyBh biBpbnZhbGlkIHBhY2tldC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgZGVmaW5pdGVseSBub3QgYW4gaXNzdWUsIHRo b3VnaCwgYmVjYXVzZSB0aGUgbmV0d29yayBvcGVyYXRvciBpcyBjaG9vc2luZyB0byBkZXBsb3kg dGhpcy4gJm5ic3A7VGhleSBjYW4gYmUgcmVzcG9uc2libGUgZm9yIGVuc3VyaW5nIGNvcnJlY3Qg YmVoYXZpb3IgaWYgdGhlcmUgYXJlIGFueSBtaWRkbGVib3hlcyBpbnRlcmNlcHRpbmcgdGhlIERI Q1B2NCB0cmFmZmljIGFuZCBkb2luZyBzdHVmZiB3aXRoIGl0Lg0KICZuYnNwOyBFeHBlY3Rpbmcg dGhpcyB0byBKdXN0IFdvcmsgd2l0aCBubyBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzIHNlZW1zIHVu bmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CViZndDsgV2h5IG5lZWQgdGhpcyB0 ZXN0aW5nIHRvIGNvbmZpcm0gdGhhdCBtaWRkbGVib3hlcyBhcmVu4oCZdCBkb2luZyBiYWQgc3R1 ZmYuIElmIHlvdSBzdGljayB0byBub3JtYWwgREhDUCBzZW1hbnRpY3MsIG5vdGhpbmcgbmVlZHMg dG8gYmUgdGVzdGVkIG9yIGNoYW5nZWQgaW4geW91ciBpbmZyYXN0cnVjdHVyZS4gWWVzLCBJIGFt IGV4cGVjdGluZyB0aGlzIHRvIHdvcmsgd2l0aCBubyBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzDQog YXMgdGhpcyBpcyBTVEFOREFSRCBESENQLiBUaGUgREhDUE9GRkVSIGp1c3QgbmV2ZXIgdHVybnMg aW4gdG8gYSBESENQUkVRVUVTVCDigJMgc28gd2hhdCDigKYgdGhpcyBjYW4gaGFwcGVuIHRvZGF5 IG9uIGFsbCBESENQIG5ldHdvcmtzIGlmIHRoZSBjbGllbnQgc3RvcHMgKHBvd2VyZWQgZG93biwg ZGlzY29ubmVjdHMgZnJvbSBuZXR3b3JrKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5UaGVyZSBpcyBhIHJlYXNvbiB3aHkgREhDUCBp bmNsdWRlcyBhIHBhcmFtZXRlciByZXF1ZXN0IGxpc3Qgb3B0aW9uLiAmbmJzcDtJZiB0aGUgY2xp ZW50IGRvZXNu4oCZdCBhc2sgZm9yIHRoaXMgbmV3ZmFuZ2xlZCBvcHRpb24sIGl0IHNob3VsZG7i gJl0IHNlZSBpdC4gJm5ic3A7QW5kIHNvIHdlIGNhbiBrbm93IGZvciBzdXJlIHRoYXQgdGhlIGNs aWVudA0KIHN1cHBvcnRzIHRoaXMgY2FwYWJpbGl0eSwgYmVjYXVzZSBpdCBhc2tlZCBmb3IgaXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2Vy aWY7Y29sb3I6YmxhY2siPjxicj4NCkV2ZW4gaWYgYSBESENQIHNlcnZlciBzZW50IHRoZSBvcHRp b24gd2l0aG91dCBpdCBiZWluZyByZXF1ZXN0ZWQsIHdoeSB3b3VsZCB0aGUgY2xpZW50IHVzZSBp dCBpZiBpdCBkaWRuJ3QgYXNrIGZvciBpdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBESENQIHNlcnZlciBrbm93cyB0 aGUgY2xpZW50IHN1cHBvcnRzIHRoZSBmZWF0dXJlLCBpdCBjYW4gYXNzdW1lIHRoYXQgd2hlbiBp dCBzZW5kcyB0aGUgb3B0aW9uLCB0aGUgY2xpZW50IHdpbGwgaW1wbGVtZW50IHRoZSBzcGVjaWZp ZWQgYmVoYXZpb3IuICZuYnNwOyBJZiBpdCBkb2VzbuKAmXQga25vdyBmb3Igc3VyZSB0aGF0IHRo ZSBjbGllbnQgc3VwcG9ydHMgdGhlIGZlYXR1cmUsIHRoZW4geW91IGhhdmUgdG8NCiBkZWFsIHdp dGggYSBtdWNoIG1vcmUgY29tcGxleCBzZXQgb2YgcG9zc2libGUgYmVoYXZpb3JzLiAmbmJzcDsg V2h5IGFkZCB0aGF0IGNvbXBsZXhpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGF04oCZcyBhc3N1bWluZyB0aGF0IHRoZSBjbGll bnQgYmVoYXZlcyA8aT5jb3JyZWN0bHkuICZuYnNwOzwvaT5JZiB5b3UganVzdCBzZW5kIHRoZSBu ZXcgb3B0aW9uLCBhbm90aGVyIHBvc3NpYmlsaXR5IGlzIHRoYXQgdGhlIGNsaWVudCBjcmFzaGVz IHdoZW4gaXQgZG9lc27igJl0IHJlY29nbml6ZSB0aGUgb3B0aW9uLCBhcyB3ZSB1c2VkIHRvIHNl ZSB3aXRoIGNlcnRhaW4gcHJpbnRlcnMgSSB0aGUgbWFudWZhY3R1cmVyDQogb2Ygd2hpY2ggSSB3 aWxsIG5vdCBtZW50aW9uLiAmbmJzcDsgT3IgdGhhdCBpdCBkb2VzIHNvbWUgb3RoZXIgcmFuZG9t IHRoaW5nLiAmbmJzcDtXaHkgY2hhbmNlIGl0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CViZn dDsgSWYgYSBESENQIGNsaWVudCBjcmFzaGVzIHdoZW4gaXQgcmVjZWl2ZXMgYW4gdW5rbm93biBv cHRpb24sIG15IGd1ZXNzIGlzIHRoYXQgaXQgd291bGQgYmUgcXVpY2tseSBmaXhlZCBhcyB0aGlz IGp1c3QgaXMgYnJva2VuIGJlaGF2aW9yLiBBZ2FpbiwgSeKAmW0gbm90IHNheWluZyB0aGF0IGEg c2VydmVyIHNob3VsZCBzZW5kIHRoaXMgb3B0aW9uIGlmIGl0IHdhc27igJl0IHJlcXVlc3RlZCBi eSBhIGNsaWVudCwNCiBidXQgSeKAmW0ganVzdCBjbGFyaWZ5aW5nIHlvdXIgc3RhdGVtZW50cyB0 aGF0IGV2ZW4gaWYgYSBjbGllbnQgd2VyZSB0byBzZWUgc29tZSBhcmJpdHJhcnkgb3B0aW9uIHRo YXQgaXQgZGlkbuKAmXQgcmVxdWVzdCwgaXQgc2hvdWxkbuKAmXQgYmUgZG9pbmcgYW55dGhpbmcg d2l0aCBpdC4gQW5kLCBJIHdvdWxkIHN1c3BlY3QgdGhhdCB5b3Ugd291bGQgYmUgaGFyZCBwcmVz c2VkIHRvIGZpbmQgYSBjbGllbnQgdGhhdCBjcmFzaGVzIHdoZW4gaXQgcmVjZWl2ZXMNCiBhbiB1 bmtub3duIG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlYmZ3Q7IEkgd2lsbCBzYXkg dGhhdCBvbmUgaXNzdWUgdGhhdCBjb3VsZCBleGlzdCB3aXRoIHRoaXMgb3B0aW9uIHRoYXQgaXMg YSBiaXQgdW51c3VhbCBpcyB0aGF0IGl0IGlzIGN1cnJlbnRseSAwLWxlbmd0aC4gV2UgaGF2ZSBv bmx5IG9uZSBvdGhlciB6ZXJvLWxlbmd0aCBvcHRpb24gdGhhdCBJIHJlY2FsbCwgYW5kIHRoYXQg aXMgUmFwaWQgQ29tbWl0ICh3aGljaCBpcyBjbGllbnQgdG8gc2VydmVyLCBub3Qgc2VydmVyDQog dG8gY2xpZW50KS4gU28sIGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlcmUgYXJlIGNsaWVudHMgdGhh dCBhcmUgdW5oYXBweSBhYm91dCB6ZXJvLWxlbmd0aCBvcHRpb25zLiBCdXQgYWdhaW4sIGluIHRo ZSBpZGVhbCB3b3JsZCBubyBjbGllbnQgd2lsbCBzZWUgdGhpcyBvcHRpb24gdW5sZXNzIGl0IGhh cyByZXF1ZXN0ZWQgaXQgKGluIHRoZSBQUkwpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1D8C9B8A0F464B0294022265F86D5F0Fciscocom_-- From nobody Fri Dec 6 08:35:53 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433BF1209B4 for ; Fri, 6 Dec 2019 08:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 wwAXG-ru6Pzk for ; Fri, 6 Dec 2019 08:35:45 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEE112098F for ; Fri, 6 Dec 2019 08:35:44 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id x1so7923742iop.7 for ; Fri, 06 Dec 2019 08:35:44 -0800 (PST) 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=zd/hUNSkoK1AQoXMZ3WnJWCRwm2het/B6ZgPRKMXI98=; b=YzIydATb4F8HsMOGnE5nB23jTStYWusXmNibhQye5qiTg3YRZxRZMIS6ecUwYv9UpI t/Y090WJOGGIa0wW0CvKem8I29GgV1rJ/tBSy4gqKmUVrXUZdmUbcb+oMsdvCZzvIa88 lFdqEWZsYcDZASWn58EUQnxzmvdkbNDmWmFsEUJGMHwVWQh/MK+T21m5tQ5ib/UqZG3O 2FENTv2SXz1zIxM9xkr2tTTnWd8GhwOpyONTJyAtS11sfttPAlycqW6qrv+kbQzZ1RUn 0JjjkfogfWyrHYz+zk8o12KnGkOtR4MisCFv+FOcEqlyR6uvuGGUX+9XXRaLQpsAbVgR 3rrg== 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=zd/hUNSkoK1AQoXMZ3WnJWCRwm2het/B6ZgPRKMXI98=; b=FcWIb99P9jn/U4CWsqvdaQ5W1ijwkOOctRmn40L1F8IEB2aqO41O0JdMujMgu5Nd6e 2LP9zxQEok8JTEGQDSWl0FKWqWEJL00AvqII+0pd4kIdzZ6hOshxsXih47vt66FHXHSR EtyIUz9NmIQC2UHMNxtOUNMtsgFtP3vIGjDOi5jXJFhgsHAsRlKAMhIKUqV8pZ11ss69 aD8lfLoU5fFQLDwPIvEM1bMaKyUaSnNvpclKFPkKhAnw958IfJwLJHlgZDcW03bbUMuy TSQOaTLZYoQO+IAO/89VqA9n3TOYpQpCRDr2xBXyju3a+GiMol35yHUR4by0xj5h4Ysi 8QzQ== X-Gm-Message-State: APjAAAXeRIvvL8n05b1rVl4lsuK8t8CUg0WHAxs0uh3gpUII471yWTA/ JxlcV39vs7lHQsUA8VJaopG9H/12f8+h6P8wz0R7YvNjWgw= X-Google-Smtp-Source: APXvYqzasGEieAJ3u0pYBbkaexLLXVR99OcZ3lmcEIGeo6Jj/q6kG2LxNSbOo9IPh2K7e3GUT8v7mXBYe5jtxoSWNGk= X-Received: by 2002:a02:2909:: with SMTP id p9mr14542164jap.59.1575650143811; Fri, 06 Dec 2019 08:35:43 -0800 (PST) MIME-Version: 1.0 References: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> In-Reply-To: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> From: Lorenzo Colitti Date: Sat, 7 Dec 2019 01:35:30 +0900 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001d6e7705990ba3d1" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 16:35:53 -0000 --0000000000001d6e7705990ba3d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon wrote: > which requires fewer changes on the DHCP server implementation > > This is almost certainly not true. In order for this to work, you=E2=80= =99re > going to have to have some special-purpose code to support it. Better to > do the clean solution than a hack that minimizes changes to the server at > the expense of more complication in the client-server interaction. > I don't think this option requires any server changes other than the code to parse and serialize the option. That the server doesn't even need to know or care whether the client supports the option or not. At worst, it can simply blindly include the option on any pool that is configured to send it. Obviously, in the presence of buggy clients, the server should only send the option if it was requested, but servers typically already do that. The offer behaviour can stay the same: if the server gets a discover, it picks an address and responds with an offer from the pool. Per RFC 2131 section 3.1, that address need not be reserved, but it could be reserved for a brief time as well. Either works. If the client gets the option and decides it doesn't need IPv4, it won't send a request; after a while, the server can free the address if it had briefly reserved it. If the client wants IPv4, it will send a request and get an ack. As Bernie says, if the pool is too small for the number of clients (which it will be, if this option is to be useful), and too many clients send discovers simultaneously (e.g., they're rebooted all at the same time), then the server will either not respond with offers to some of them, or will respond with offers and be forced to nak if two clients request the same address. Things continue to work. The current text in the draft proposes an optimization on top of that: If the pool is explicitly configured with a dedicated IPv4 address to be returned to IPv6-only capable clients the server MUST specify that address as the client's network address and MUST NOT verify its uniqueness. Otherwise the server SHOULD follow the recommendations in [RFC2131]. The client is not expected to use that IPv4 address so if the client responds with the DHCPREQUEST message for that address the server SHOULD respond with DHCPNAK. This does indeed require code changes on the server side. But I think it would be good if such changes were optional. Additionally, this optimization creates the problem that if the client and responds to the nak with a discover, and the server replies with the same offer as before, then the client could gets stuck in a loop. Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and > always include an address because you never know how intermediate devices > that may be "snooping" this traffic will handle this; for example, the > intermediate device might drop what it feels is an invalid packet. > > > This is definitely not an issue, though, because the network operator is > choosing to deploy this. They can be responsible for ensuring correct > behavior if there are any middleboxes intercepting the DHCPv4 traffic and > doing stuff with it. Expecting this to Just Work with no infrastructure > changes seems unnecessary. > I don't think this is a good justification for doing things that could break compatibility. It's true that the network operator is choosing to deploy this. But the network operator may not fully control all the devices on the network, and even if they do, fixing bugs is expensive: the bug needs to be reported, the vendor (assuming they're still around) might need to be convinced that it's a bug, code changes need to be made, the device may need to be updated to a substantially newer version, software needs to be re-qualified, etc. I agree with Bernie that if we can avoid changing the observed behaviour, that would be better. --0000000000001d6e7705990ba3d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon = <mellon@fugue.com> wrote:
=
which requir= es fewer changes on the DHCP server implementation
This is almost certainly not true.=C2=A0 In order for this to w= ork, you=E2=80=99re going to have to have some special-purpose code to supp= ort it.=C2=A0 Better to do the clean solution than a hack that minimizes ch= anges to the server at the expense of more complication in the client-serve= r interaction.

I don't thin= k this option requires any server changes other than the code to parse and = serialize the option. That the server doesn't even need to know or care= whether the client supports the option or not. At worst, it can simply bli= ndly include the option on any pool that is configured to send it. Obviousl= y, in the presence of buggy clients, the server should only send the option= if it was requested, but servers typically already do that. The offer beha= viour can stay the same: if the server gets a discover, it picks an address= and responds with an offer from the pool. Per RFC 2131 section 3.1, that a= ddress=C2=A0need not be reserved, but it could be reserved for a brief time= as well. Either works. If the client gets the option and decides it doesn&= #39;t need IPv4, it won't send a request; after a while, the server can= free the address if it had briefly reserved it. If the client wants IPv4, = it will send a request and get an ack.

As Bernie s= ays, if the pool is too small for the number of clients (which it will be, = if this option is to be useful), and too many clients send discovers simult= aneously (e.g., they're rebooted all at the same time), then the server= will either not respond with offers to some of them, or will respond with = offers and be forced to nak if two clients request the same address. Things= continue to work.

The current text in the draft p= roposes an optimization on top of that:

=C2=A0= =C2=A0If the pool is explicitly configured with a dedicated IPv4
=C2=A0= =C2=A0address to be returned to IPv6-only capable clients the server MUST<= br>=C2=A0 =C2=A0specify that address as the client's network address an= d MUST NOT
=C2=A0 =C2=A0verify its uniqueness.=C2=A0 Otherwise the serve= r SHOULD follow the
=C2=A0 =C2=A0recommendations in [RFC2131].=C2=A0 The= client is not expected to use that
=C2=A0 =C2=A0IPv4 address= so if the client responds with the DHCPREQUEST message
=C2=A0 =C2=A0for= that address the server SHOULD respond with DHCPNAK.

This does indeed require code changes on the server side. But I thi= nk it would be good if such changes were optional. Additionally, this optim= ization creates the problem that if the client and responds to the nak with= a discover, and the server replies with the same offer as before, then the= client could gets stuck in a loop.

=
Personally, I would NOT recommend breaking the semantics of = a DHCPOFFER and always include an address because you never know how interm= ediate devices that may be "snooping" this traffic will handle th= is; for example, the intermediate device might drop what it feels is an inv= alid packet.

This is definitely not an is= sue, though, because the network operator is choosing to deploy this.=C2=A0= They can be responsible for ensuring correct behavior if there are any mid= dleboxes intercepting the DHCPv4 traffic and doing stuff with it. =C2=A0 Ex= pecting this to Just Work with no infrastructure changes seems unnecessary.=

I don't think this is a go= od justification for doing things that could break compatibility. It's = true that the network operator is choosing to deploy this. But the network = operator may not fully control all the devices on the network, and even if = they do, fixing bugs is expensive: the bug needs to be reported, the vendor= (assuming they're still around) might need to be convinced that it'= ;s a bug, code changes need to be made, the device may need to be updated t= o a substantially newer version, software needs to be re-qualified, etc. I = agree with Bernie that if we can avoid changing the observed behaviour, tha= t would be better.
--0000000000001d6e7705990ba3d1-- From nobody Fri Dec 6 10:55:14 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2967120059 for ; Fri, 6 Dec 2019 10:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jNA4YDLoOIjO for ; Fri, 6 Dec 2019 10:55:07 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D769D12004A for ; Fri, 6 Dec 2019 10:55:07 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id q8so3775829pfh.7 for ; Fri, 06 Dec 2019 10:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=D0VIDHDokhujXqnqc4/mYAGY0ECi6RDB7zRvigYt7aU=; b=N5fcw6mX+IEMVyzRvcUHSNBG8Q1TM0qEkK2OEgNOMGj3gYuA2bh6IxPsL8vBrvAoPJ N0zjIdV2YHWwbibNKaHAIydK/npj8l3Dfkqm8c+mjpwgdk/PmrjJK/AMqQAC+tgrX++Z WPtQOJzf5wtdoQizH7G9f66XjKGsTYg1ZkkmdIUMSs73AKBVxv8vtzV9LYcXZs07M16r RYntTckMBK7ZOqREOD2+Yjh7JjSwLjQnqZ0l45PSS+bjAWxGFjHz1Z7MefHESE6PiuVo 4xzP5LgwQGOX0bevTbEaQfLI3C4UPs49PGIybpNGaD4iYudUhQn0UDNtSoaZWtBbVgeh Zr6g== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=D0VIDHDokhujXqnqc4/mYAGY0ECi6RDB7zRvigYt7aU=; b=kgOZ0JHMQ0RNAq/E6tzWUqMbrk3Xa0scm2NM2CrjP2BdKwc36Z4b+7cEY+SHFOBFKP aDJiTyNQzNAZnki3l0Efu1ZMgGDnSoY59RUTndV+Ixrn5KF4UOwWFpz05TYgWhHJNhLE piOU0QIbfjU9vLbiwdapDLmqecEdOnUUAk0//XDLoPaoX0WjDicJrEL8X94e4mEKtb0m vgdOqbKeCHtafDie8IRcvZKxC18+w133ECdbYUdQA4mXTnw5odFqw1vGyNwcpDBUn9jC GHrd+WHuZHNqvnD0l3/fnuLkFkLPgyxxNI3j39VpRGrq15Ro2OiMYW2ZxkQnj0k2jAu1 4ipg== X-Gm-Message-State: APjAAAXt19dWazbpxzD5GP6TSMjdmibXjq58ur5Ljfcbs6i42NiErmXN dr9ODZsVts81lOgG+HqBihZ9eA== X-Google-Smtp-Source: APXvYqwVp2NhLd8lgW9hYTHd9wVgkFhP0QONXYXPxGA28xESnHo/e6B2I7Y1G0X5A8uasvkaDfJ6CA== X-Received: by 2002:a62:3141:: with SMTP id x62mr16306354pfx.214.1575658507298; Fri, 06 Dec 2019 10:55:07 -0800 (PST) Received: from [17.230.159.70] ([17.230.159.70]) by smtp.gmail.com with ESMTPSA id z30sm17011527pff.131.2019.12.06.10.55.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Dec 2019 10:55:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-060F0663-9B3D-4C3E-B270-FD92C7D65330 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 6 Dec 2019 10:55:05 -0800 Message-Id: <1D60C687-E163-4C66-874C-1349F7219740@fugue.com> References: Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "v6ops@ietf.org" In-Reply-To: To: Lorenzo Colitti X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 18:55:11 -0000 --Apple-Mail-060F0663-9B3D-4C3E-B270-FD92C7D65330 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lorenzo, it might help for you to make explicit why you do not want to requi= re changes on the server. This seems like a short sicher choice for a soluti= on that=E2=80=99s going to be deployed for a long time. Why not do it right g= iven we=E2=80=99re going to have to live with it for decades? > On Dec 6, 2019, at 08:35, Lorenzo Colitti wrote: >=20 > =EF=BB=BF > On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon wrote: >>> which requires fewer changes on the DHCP server implementation >>=20 >> This is almost certainly not true. In order for this to work, you=E2=80=99= re going to have to have some special-purpose code to support it. Better to= do the clean solution than a hack that minimizes changes to the server at t= he expense of more complication in the client-server interaction. >=20 > I don't think this option requires any server changes other than the code t= o parse and serialize the option. That the server doesn't even need to know o= r care whether the client supports the option or not. At worst, it can simpl= y blindly include the option on any pool that is configured to send it. Obvi= ously, in the presence of buggy clients, the server should only send the opt= ion if it was requested, but servers typically already do that. The offer be= haviour can stay the same: if the server gets a discover, it picks an addres= s and responds with an offer from the pool. Per RFC 2131 section 3.1, that a= ddress need not be reserved, but it could be reserved for a brief time as we= ll. Either works. If the client gets the option and decides it doesn't need I= Pv4, it won't send a request; after a while, the server can free the address= if it had briefly reserved it. If the client wants IPv4, it will send a req= uest and get an ack. >=20 > As Bernie says, if the pool is too small for the number of clients (which i= t will be, if this option is to be useful), and too many clients send discov= ers simultaneously (e.g., they're rebooted all at the same time), then the s= erver will either not respond with offers to some of them, or will respond w= ith offers and be forced to nak if two clients request the same address. Thi= ngs continue to work. >=20 > The current text in the draft proposes an optimization on top of that: >=20 > If the pool is explicitly configured with a dedicated IPv4 > address to be returned to IPv6-only capable clients the server MUST > specify that address as the client's network address and MUST NOT > verify its uniqueness. Otherwise the server SHOULD follow the > recommendations in [RFC2131]. The client is not expected to use that > IPv4 address so if the client responds with the DHCPREQUEST message > for that address the server SHOULD respond with DHCPNAK. >=20 > This does indeed require code changes on the server side. But I think it w= ould be good if such changes were optional. Additionally, this optimization c= reates the problem that if the client and responds to the nak with a discove= r, and the server replies with the same offer as before, then the client cou= ld gets stuck in a loop. >=20 >>> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER a= nd always include an address because you never know how intermediate devices= that may be "snooping" this traffic will handle this; for example, the inte= rmediate device might drop what it feels is an invalid packet. >>=20 >> This is definitely not an issue, though, because the network operator is c= hoosing to deploy this. They can be responsible for ensuring correct behavi= or if there are any middleboxes intercepting the DHCPv4 traffic and doing st= uff with it. Expecting this to Just Work with no infrastructure changes se= ems unnecessary. >=20 > I don't think this is a good justification for doing things that could bre= ak compatibility. It's true that the network operator is choosing to deploy t= his. But the network operator may not fully control all the devices on the n= etwork, and even if they do, fixing bugs is expensive: the bug needs to be r= eported, the vendor (assuming they're still around) might need to be convinc= ed that it's a bug, code changes need to be made, the device may need to be u= pdated to a substantially newer version, software needs to be re-qualified, e= tc. I agree with Bernie that if we can avoid changing the observed behaviour= , that would be better. --Apple-Mail-060F0663-9B3D-4C3E-B270-FD92C7D65330 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lorenzo, it might help for= you to make explicit why you do not want to require changes on the server. T= his seems like a short sicher choice for a solution that=E2=80=99s going to b= e deployed for a long time. Why not do it right given we=E2=80=99re going to= have to live with it for decades?

On Dec 6, 2019, at 08:35, Lorenzo Colitti <lorenzo@google.com&= gt; wrote:

=EF=BB=BF
On Sat, Dec 7, 2019 at 1:02 A= M Ted Lemon <mellon@fugue.com>= wrote:
which req= uires fewer changes on the DHCP server implementation
This is almost certainly not true.  In order for this to w= ork, you=E2=80=99re going to have to have some special-purpose code to suppo= rt it.  Better to do the clean solution than a hack that minimizes chan= ges to the server at the expense of more complication in the client-server i= nteraction.

I don't think this o= ption requires any server changes other than the code to parse and serialize= the option. That the server doesn't even need to know or care whether the c= lient supports the option or not. At worst, it can simply blindly include th= e option on any pool that is configured to send it. Obviously, in the presen= ce of buggy clients, the server should only send the option if it was reques= ted, but servers typically already do that. The offer behaviour can stay the= same: if the server gets a discover, it picks an address and responds with a= n offer from the pool. Per RFC 2131 section 3.1, that address need not b= e reserved, but it could be reserved for a brief time as well. Either works.= If the client gets the option and decides it doesn't need IPv4, it won't se= nd a request; after a while, the server can free the address if it had brief= ly reserved it. If the client wants IPv4, it will send a request and get an a= ck.

As Bernie says, if the pool is too small for th= e number of clients (which it will be, if this option is to be useful), and t= oo many clients send discovers simultaneously (e.g., they're rebooted all at= the same time), then the server will either not respond with offers to some= of them, or will respond with offers and be forced to nak if two clients re= quest the same address. Things continue to work.

Th= e current text in the draft proposes an optimization on top of that:

   If the pool is explicitly configured with= a dedicated IPv4
   address to be returned to IPv6-only capabl= e clients the server MUST
   specify that address as the client= 's network address and MUST NOT
   verify its uniqueness. = Otherwise the server SHOULD follow the
   recommendations in [= RFC2131].  The client is not expected to use that
  &= nbsp;IPv4 address so if the client responds with the DHCPREQUEST message
=    for that address the server SHOULD respond with DHCPNAK.

This does indeed require code changes on the server s= ide. But I think it would be good if such changes were optional. Additionall= y, this optimization creates the problem that if the client and responds to t= he nak with a discover, and the server replies with the same offer as before= , then the client could gets stuck in a loop.

Personally, I would NOT recommend breaking the semantics o= f a DHCPOFFER and always include an address because you never know how inter= mediate devices that may be "snooping" this traffic will handle this; for ex= ample, the intermediate device might drop what it feels is an invalid packet= .

This is definitely not an issue, though,= because the network operator is choosing to deploy this.  They can be r= esponsible for ensuring correct behavior if there are any middleboxes interc= epting the DHCPv4 traffic and doing stuff with it.   Expecting this to J= ust Work with no infrastructure changes seems unnecessary.

I don't think this is a good justification for do= ing things that could break compatibility. It's true that the network operat= or is choosing to deploy this. But the network operator may not fully contro= l all the devices on the network, and even if they do, fixing bugs is expens= ive: the bug needs to be reported, the vendor (assuming they're still around= ) might need to be convinced that it's a bug, code changes need to be made, t= he device may need to be updated to a substantially newer version, software n= eeds to be re-qualified, etc. I agree with Bernie that if we can avoid chang= ing the observed behaviour, that would be better.
= --Apple-Mail-060F0663-9B3D-4C3E-B270-FD92C7D65330-- From nobody Fri Dec 6 13:42:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E1120074 for ; Fri, 6 Dec 2019 13:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 awzKAmQ0NOcd for ; Fri, 6 Dec 2019 13:42:09 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEC412002F for ; Fri, 6 Dec 2019 13:42:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 66A1B1A071 for ; Fri, 6 Dec 2019 21:42:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Hobson In-Reply-To: <1D60C687-E163-4C66-874C-1349F7219740@fugue.com> Date: Fri, 6 Dec 2019 21:42:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D60C687-E163-4C66-874C-1349F7219740@fugue.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 21:42:12 -0000 Mark Smith wrote: > - IPv6 only applications clearly indicate they're IPv6 only, by only > opening IPv6 sockets. I think "IPv6 only" applications are a rare thing, and will remain so = for a long time. Applications that can use IPv4 or IPv6, and which can = work fine in IPv6 if IPv4 isn't available, are likely to be the norm for = some time. For an application to signal such compatibility modes to the OS would = need substantial changes to the interaction model between application = and OS. In the general case, that's just not going to happen. > Ted Lemon wrote: > Lorenzo, it might help for you to make explicit why you do not want to = require changes on the server. This seems like a short sicher choice for = a solution that=E2=80=99s going to be deployed for a long time. Why not = do it right given we=E2=80=99re going to have to live with it for = decades? As previously described in terms of identifying bugs in intermediate = equipment, raising bug reports, persuading the vendor (if they are still = around and the kit is still in support) to fix it, and then rolling out = the fix ... Why require changes in DHCP servers when it can be done without any code = changes at all ? Perhaps define the option such that DHCP server vendors can, if they so = desire, code in some optimisations - but I would say that allowing it to = work without code changes would be much better. There is one thought that comes to mind ... In effect, where this option = is deployed, then (native) IPv4 is considered a legacy protocol that's = being deprecated - why invest more effort than needed in supporting it. From nobody Fri Dec 6 14:07:50 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0EC1200CC; Fri, 6 Dec 2019 14:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=QZfMKzc9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SFDHYk8i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDnEdYAhvko8; Fri, 6 Dec 2019 14:07:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA0912006B; Fri, 6 Dec 2019 14:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5916; q=dns/txt; s=iport; t=1575670062; x=1576879662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ib0ikubzsqQjhk4jAX5Q2YFfpmy/ZAwU8wOm280OyxQ=; b=QZfMKzc919v6y6l6j2DepK6XU9kT8/ymQEQy2UxEofXiRMyqqG5eEQTA ENZbZgoKSXifOHUwTw6lREuOceb0y2tLFys5SRt+y/uuj32d5SFoz0f1y ubPN8b3Bzc+NJgAVtmlxiLKBDHOgG9pxUr0EKBcRtipRD87wSl5bnZe2e 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Ah11qABIAKDh+hQM4jtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQBX0Opd/4wNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgW0EAQELAYFKUAVsWCAECyoKhCKDRgOLAIJfgQGIWo4qglIDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEQAIXgX4kNwYOAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQE?= =?us-ascii?q?CAQEBEBERDAEBLAsBBAcEAgEIDgMEAQEDAiYCAgIfBgsVCAgCBAENBQgTB4M?= =?us-ascii?q?BgkYDDiABAgyhVQKBOIhhdYEygn4BAQWBNQGDUw0LghcDBoEOKAGMFxqCAIE?= =?us-ascii?q?RR4IXNT6CG0kBAYFNGIMOMoIsjWuCPJ1xQwqCLpFHhDmaMY5KilqPUAIEAgQ?= =?us-ascii?q?FAg4BAQWBaCOBWHAVO4JsUBEUjGaDc4UUhT90gSiMQAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,286,1571702400"; d="scan'208";a="671948132" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2019 22:07:41 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xB6M7fGA005327 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2019 22:07:41 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 16:07:40 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 17:07:39 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Dec 2019 17:07:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=crRtOCQSaiPsjEZDM+JvJSedScFtQ/7MD1F36v1WOdJn19vpAzyhRwzEXIXy73gqp82O9JFv6f8JGBF6Sw9B6VQRTBUBEW4DNuGG3iFM7OXsvNndF3ud5vQNUjF/AZ31nVCZSnvug38re8BSfIIapoRjop+lIBSAPOMnyWfSrBSZIp4jW5fkyHpVycw5yM1CzHFA4Xf0I8W9Ldb0x3eyZbVUkXsYXUi99ca5Q+dQnHu6fVpSUB5ta140R/IDtM86U3JMK5PZYboir59z+zz43Icyf5Ki8S9i89dAVBHey6V9lvCSRyIpGkjGW1l84VC1Gx+L81GA77JNKmLO7HSUwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ib0ikubzsqQjhk4jAX5Q2YFfpmy/ZAwU8wOm280OyxQ=; b=M8bfDv+325IcNVuyoXRmkpiZlMTx5USOK37Zxls1bGSOqYPkBpGlPcthJRHcISyrpLQUnQ4av7sMhBNFNgtky0O7QlVT6IR+7MEKKiGCIt0sGQoAEhZTE+P4nFKFB/qv1av5zK2/Wnk8b1UQESNK3lsvpUmYeJJQUwE0AET8ABYzAsWB/LRX5Er/F/8IQcvVNA6y8vUykpkrOTvPZxR93nYDkVIRog95JzjeAPhhDyWCtnM3RU8FCDMU+CjmVTfFiSc2mliJcS45mbS09wNtZN1UrVHTscfLO7HPSC0QKNbsjg6BDqWo6b5dWyazxhAuQlldowX5foxvJodX34z/jQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ib0ikubzsqQjhk4jAX5Q2YFfpmy/ZAwU8wOm280OyxQ=; b=SFDHYk8iCt09Ia2tyhvSymrVwMHi8h6AQo4rwKcTuzwKK0n3x2U1Bozsl3m8yWfM3b/sHPg4kF5fXNL6ev9viOvTYqvgObTU49JKt/7I1F86Ord/4ws2tnI4yYvPJehA8I2iUgr+Gz0F+0TlDmYx/CNhHBKgDTXhurW1wJD/2vQ= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB2956.namprd11.prod.outlook.com (20.177.217.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12; Fri, 6 Dec 2019 22:07:38 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.017; Fri, 6 Dec 2019 22:07:38 +0000 From: "Bernie Volz (volz)" To: Simon Hobson , "v6ops@ietf.org" , Ted Lemon CC: "dhcwg@ietf.org" Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrEHbgQve9DKh2EKQEqgwr7Y10qetK3KQgAAZCACAAAlaAIAAJwCAgAAupoCAAAGt4A== Date: Fri, 6 Dec 2019 22:07:38 +0000 Message-ID: References: <1D60C687-E163-4C66-874C-1349F7219740@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b94d8878-43b0-4e3e-7bc5-08d77a98b4ee x-ms-traffictypediagnostic: DM6PR11MB2956: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(136003)(366004)(376002)(13464003)(199004)(189003)(55016002)(9686003)(229853002)(966005)(186003)(26005)(102836004)(478600001)(53546011)(76176011)(6506007)(2906002)(81166006)(8676002)(8936002)(33656002)(305945005)(7696005)(71200400001)(74316002)(81156014)(71190400001)(76116006)(64756008)(4326008)(52536014)(66446008)(66946007)(66476007)(316002)(66556008)(99286004)(86362001)(5660300002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2956; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9vsvT31aQLtijzqyGsHcUgIM1YVJYCXTAteEu0VD7G6+O5TeabJjULJKNY/Ka2geFh0BnyhXR0jaTv5+CtKcHCcTU87r9bwOvRDIwAPxL8G4IrafDxD5gCNMf2YInIPLOQ2o6LqTLFCw+mD5uhGLZbGfeaEL4zvddpOXlGIPzVmFZjsR+YWfBfp1eSfz80N6qtHzrvstAq1PfbZhZqLRpI6VBc96ezG+fFk3L1t8KBA0gTF/izU3VEZLGbM/G3yVw6xV8njiLWWyK4zDevRIZ1N3tQBsne63c/8ZAXTi/Fr92VsJhMcmjHH3Ra/EK8XucSCC8NFhrM/PKO6UO2QCSegSsErcyi1kpy1j7LRZ3JzEDWxZJwWaESCK+h0VyZXnOn+ZR3oKmCRuKskQ5sc5bQS+oF/YJNt8KS45DLHXNi/LXdZNmOaz34Uxd6q9N6MxatBaM8NKuVrnZlLCxNCL0vpjIicYzSK6hK57hiiHIhnTpYFyHWSCTzOn1uoR6Et3R57HQJuMfe3A7/qF6cGRwU0Ua6BukL+UMKIpaKnrddE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b94d8878-43b0-4e3e-7bc5-08d77a98b4ee X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 22:07:38.3811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: liwmm4CRLisn5xXJ2HDTpzwgsWV7tSt2zSk+hI7qH+HhDm4paOKjaOnJiOhSkHJL X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2956 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 22:07:44 -0000 SSBmdWxseSBhZ3JlZSAobm8gc2VydmVyIGNoYW5nZXMsIG1pbmltdW0gaW52ZXN0bWVudCBmb3Ig REhDUHY0KS4NCg0KU28gd2hlcmUgYXJlIHRoZXNlIHByb3Bvc2VkIGNoYW5nZXMgdG8gYmUgZG9u ZSBhbnl3YXk/DQoNCkluIHRlcm1zIG9mIGFkZGluZyBuZXcgb3B0aW9ucywgdGhpcyBoYXBwZW5z IGJ5IElFVEYvSUFOQSBhbGwgb2YgdGhlIHRpbWUgYW5kIG1vc3Qgc2VydmVycywgd2hpbGUgdGhl eSBtYXkgc2hpcCB3aXRoIGEgcHJlLWNvbmZpZ3VyZSBzZXQsIHN1cHBvcnQgZGVmaW5pbmcgbmV3 IG9wdGlvbnMgYW5kIGNvbmZpZ3VyaW5nIGluc3RhbmNlcyBvZiB0aGVzZSBvcHRpb25zLiBBbmQs IHNlcnZlcnMgYWxyZWFkeSBoYXZlIHRoZSBsb2dpYyB0byByZXR1cm4gYSBjb25maWd1cmVkIG9w dGlvbiBpZiB0aGUgY2xpZW50IHNlbmRzIHRoYXQgb3B0aW9uIGluIGl0cyBQYXJhbWV0ZXIgUmVx dWVzdCBMaXN0IG9wdGlvbi4NCg0KQW5kLCBpbiB0ZXJtcyBvZiB0aGUgREhDUERJU0NPVkVSIG5l dmVyIHRyYW5zaXRpb25pbmcgdG8gYSBESENQUkVRVUVTVCwgd2hhdCBoZXJlIG5lZWRzIGNoYW5n aW5nPyBSRkMyMTMxIGlzIGNsZWFyIHRoYXQgdGhlcmUgYXJlIG5vIGlzc3VlcyB3aXRoIHRoaXMg YXMgc2VjdGlvbiA0LjMuMiBzdGF0ZXM6DQoNCiAgICAgICAgIC4uLiBCZWNhdXNlDQogICAgICB0 aGUgc2VydmVycyBoYXZlIG5vdCBjb21taXR0ZWQgYW55IG5ldHdvcmsgYWRkcmVzcyBhc3NpZ25t ZW50cyBvbg0KICAgICAgdGhlIGJhc2lzIG9mIGEgREhDUE9GRkVSLCBzZXJ2ZXJzIGFyZSBmcmVl IHRvIHJldXNlIG9mZmVyZWQNCiAgICAgIG5ldHdvcmsgYWRkcmVzc2VzIGluIHJlc3BvbnNlIHRv IHN1YnNlcXVlbnQgcmVxdWVzdHMuICBBcyBhbg0KICAgICAgaW1wbGVtZW50YXRpb24gZGV0YWls LCBzZXJ2ZXJzIFNIT1VMRCBOT1QgcmV1c2Ugb2ZmZXJlZCBhZGRyZXNzZXMNCiAgICAgIGFuZCBt YXkgdXNlIGFuIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIHRpbWVvdXQgbWVjaGFuaXNtIHRvIGRl Y2lkZQ0KICAgICAgd2hlbiB0byByZXVzZSBhbiBvZmZlcmVkIGFkZHJlc3MuDQoNClNlY3Rpb24g My4xIGFsc28gaGFzOg0KDQogICAgICAgICAgICAgICAgIC4uLiBTZXJ2ZXJzIG5lZWQgbm90DQog ICAgICByZXNlcnZlIHRoZSBvZmZlcmVkIG5ldHdvcmsgYWRkcmVzcywgYWx0aG91Z2ggdGhlIHBy b3RvY29sIHdpbGwNCiAgICAgIHdvcmsgbW9yZSBlZmZpY2llbnRseSBpZiB0aGUgc2VydmVyIGF2 b2lkcyBhbGxvY2F0aW5nIHRoZSBvZmZlcmVkDQogICAgICBuZXR3b3JrIGFkZHJlc3MgdG8gYW5v dGhlciBjbGllbnQuDQoNCihJbiB0aGUgc2VydmVyIEkgd29yayBvbiwgd2UgdG9vayB0aGF0IGF2 b2lkcyB0byBtZWFuIHdpdGhpbiBhIHJlYXNvbmFibHkgc2hvcnQgdGltZSBwZXJpb2QgLSBieSBk ZWZhdWx0IDIgbWludXRlcyB0aG91Z2ggY29uZmlndXJhYmxlLikNCg0KSXMgaXQgdGhlIHBvdGVu dGlhbCBwcm9iaW5nIG9mIGFuIGFkZHJlc3MgYmVmb3JlIG9mZmVyaW5nIGl0PyBJcyBzbywgd2hh dCdzIHRoZSBoYXJtPyAoQW5kIFJGQzIxMzEgcmVjb21tZW5kcyB0aGlzIGJlIGNvbmZpZ3VyYWJs ZSBhcyB0byB3aGV0aGVyIGl0IGhhcHBlbnMuKQ0KDQpTdXJlLCB0aGVyZSBhcmUgdGhpbmdzIHlv dSBtaWdodCBkbyB0byBvcHRpbWl6ZSAoc3VjaCBhcyB3aGF0IHdhcyBtZW50aW9uZWQgaW4gdGhl IGRyYWZ0KSwgYnV0IEkgZG9uJ3Qgc2VlIHRoYXQgYmVpbmcgbmVjZXNzYXJ5IGF0IGFsbCBmb3Ig dGhpcyBkZXBsb3ltZW50LiBBbmQsIGluIHNvbWUgY2FzZXMgKHN1Y2ggYXMgaWYgdGhlIGNsaWVu dCB3aGVyZSB0byBoYXZlIGNoYW5nZWQgaXRzIG1pbmQgYmV0d2VlbiB0aGUgREhDUERJU0NPVkVS IGFuZCB3aGVuIERIQ1BPRkZFUiBpcyByZXR1cm5lZCwgcGVyaGFwcyBpdCBpcyBhIGJhZCB0aGlu ZyAtIHNpbmNlIHlvdSBuZXZlciByZWFsbHkgd2FudCB0byBsZWFzZSB0aGF0IGFkZHJlc3MgYW5k IHRoaXMgd291bGQgcmVxdWlyZSBhZGRpdGlvbmFsIHNwZWNpYWwgbG9naWMpLiBBZnRlciB0aGUg ZGlzY3Vzc2lvbnMsIEkganVzdCBjYW4ndCBzZWUgdGhpcyBvcHRpbWl6YXRpb24gYmVpbmcgd29y dGggaXQgc2luY2UgaWYgYWxsIGFkZHJlc3NlcyBhcmUgaW4gdXNlLCB0aGUgY2xpZW50IGp1c3Qg ZW5kcyB1cCBzZW5kaW5nIERIQ1BESVNDT1ZFUnMgKHdoaWNoIHNlcnZlciBkcm9wcyBpZiBpdCBj YW5ub3QgYXNzaWduIGEgbGVhc2UpLiBCdXQgb3RoZXIgdGhhbiB3YXN0aW5nIHNvbWUgcGFja2V0 cyBhbmQgdGltZSBiZWZvcmUgREhDUHY0IGlzIGRpc2FibGVkLCB0aGVyZSdzIG5vIGhhcm0uDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgU2ltb24gSG9ic29uDQpTZW50OiBGcmlkYXksIERlY2Vt YmVyIDYsIDIwMTkgNDo0MiBQTQ0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2 b3BzXSBJUHY2LU9ubHkgUHJlZmVycmVkIERIQ1B2NCBvcHRpb24NCg0KTWFyayBTbWl0aCA8bWFy a3p6enNtaXRoQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4gLSBJUHY2IG9ubHkgYXBwbGljYXRpb25z IGNsZWFybHkgaW5kaWNhdGUgdGhleSdyZSBJUHY2IG9ubHksIGJ5IG9ubHkgDQo+IG9wZW5pbmcg SVB2NiBzb2NrZXRzLg0KDQpJIHRoaW5rICJJUHY2IG9ubHkiIGFwcGxpY2F0aW9ucyBhcmUgYSBy YXJlIHRoaW5nLCBhbmQgd2lsbCByZW1haW4gc28gZm9yIGEgbG9uZyB0aW1lLiBBcHBsaWNhdGlv bnMgdGhhdCBjYW4gdXNlIElQdjQgb3IgSVB2NiwgYW5kIHdoaWNoIGNhbiB3b3JrIGZpbmUgaW4g SVB2NiBpZiBJUHY0IGlzbid0IGF2YWlsYWJsZSwgYXJlIGxpa2VseSB0byBiZSB0aGUgbm9ybSBm b3Igc29tZSB0aW1lLg0KDQpGb3IgYW4gYXBwbGljYXRpb24gdG8gc2lnbmFsIHN1Y2ggY29tcGF0 aWJpbGl0eSBtb2RlcyB0byB0aGUgT1Mgd291bGQgbmVlZCBzdWJzdGFudGlhbCBjaGFuZ2VzIHRv IHRoZSBpbnRlcmFjdGlvbiBtb2RlbCBiZXR3ZWVuIGFwcGxpY2F0aW9uIGFuZCBPUy4gSW4gdGhl IGdlbmVyYWwgY2FzZSwgdGhhdCdzIGp1c3Qgbm90IGdvaW5nIHRvIGhhcHBlbi4NCg0KDQoNCj4g VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3cm90ZToNCg0KPiBMb3JlbnpvLCBpdCBtaWdo dCBoZWxwIGZvciB5b3UgdG8gbWFrZSBleHBsaWNpdCB3aHkgeW91IGRvIG5vdCB3YW50IHRvIHJl cXVpcmUgY2hhbmdlcyBvbiB0aGUgc2VydmVyLiBUaGlzIHNlZW1zIGxpa2UgYSBzaG9ydCBzaWNo ZXIgY2hvaWNlIGZvciBhIHNvbHV0aW9uIHRoYXTigJlzIGdvaW5nIHRvIGJlIGRlcGxveWVkIGZv ciBhIGxvbmcgdGltZS4gV2h5IG5vdCBkbyBpdCByaWdodCBnaXZlbiB3ZeKAmXJlIGdvaW5nIHRv IGhhdmUgdG8gbGl2ZSB3aXRoIGl0IGZvciBkZWNhZGVzPw0KDQpBcyBwcmV2aW91c2x5IGRlc2Ny aWJlZCBpbiB0ZXJtcyBvZiBpZGVudGlmeWluZyBidWdzIGluIGludGVybWVkaWF0ZSBlcXVpcG1l bnQsIHJhaXNpbmcgYnVnIHJlcG9ydHMsIHBlcnN1YWRpbmcgdGhlIHZlbmRvciAoaWYgdGhleSBh cmUgc3RpbGwgYXJvdW5kIGFuZCB0aGUga2l0IGlzIHN0aWxsIGluIHN1cHBvcnQpIHRvIGZpeCBp dCwgYW5kIHRoZW4gcm9sbGluZyBvdXQgdGhlIGZpeCAuLi4NCldoeSByZXF1aXJlIGNoYW5nZXMg aW4gREhDUCBzZXJ2ZXJzIHdoZW4gaXQgY2FuIGJlIGRvbmUgd2l0aG91dCBhbnkgY29kZSBjaGFu Z2VzIGF0IGFsbCA/DQoNClBlcmhhcHMgZGVmaW5lIHRoZSBvcHRpb24gc3VjaCB0aGF0IERIQ1Ag c2VydmVyIHZlbmRvcnMgY2FuLCBpZiB0aGV5IHNvIGRlc2lyZSwgY29kZSBpbiBzb21lIG9wdGlt aXNhdGlvbnMgLSBidXQgSSB3b3VsZCBzYXkgdGhhdCBhbGxvd2luZyBpdCB0byB3b3JrIHdpdGhv dXQgY29kZSBjaGFuZ2VzIHdvdWxkIGJlIG11Y2ggYmV0dGVyLg0KDQpUaGVyZSBpcyBvbmUgdGhv dWdodCB0aGF0IGNvbWVzIHRvIG1pbmQgLi4uIEluIGVmZmVjdCwgd2hlcmUgdGhpcyBvcHRpb24g aXMgZGVwbG95ZWQsIHRoZW4gKG5hdGl2ZSkgSVB2NCBpcyBjb25zaWRlcmVkIGEgbGVnYWN5IHBy b3RvY29sIHRoYXQncyBiZWluZyBkZXByZWNhdGVkIC0gd2h5IGludmVzdCBtb3JlIGVmZm9ydCB0 aGFuIG5lZWRlZCBpbiBzdXBwb3J0aW5nIGl0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Sun Dec 8 15:54:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9812006E for ; Sun, 8 Dec 2019 15:54:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWro9jAYxCYn for ; Sun, 8 Dec 2019 15:53:59 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECF712002F for ; Sun, 8 Dec 2019 15:53:59 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id g17so7813533qtp.11 for ; Sun, 08 Dec 2019 15:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2j5FiJeMPGgRuD8WkJtWrk6RJBza6iCb0As/yd6fUgo=; b=GUEcdbbfs+z7FGjJBV99MXpgDhFcgegK8EmNqAdSii16kCzvIo8T8mUcxtsBvii8dt TAuZbXSALHa37HN0riM93UL0WgBWfOMiu1xGanH9fZdm3LAPkneycPhjtfrS23rdFB+Z CfYv/eqdB5p24O1w239aoEq2/Ura2zJ7CQeAPI5qSPAEtxjRzg2L+xUvHsKhYSsGB376 3p/i6xmGxbzj7lAqE4Z/w40qGxMB56iNEwU003kBnx+/gdR7NcOET59qUz2DFqwiOP9i Hzrm+kbi9svOZ1E4qFZS+/aiJkl1weklUcUO9Ag399u4aXf9I6E97FE+i6fHgbyES+8c tsUg== 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=2j5FiJeMPGgRuD8WkJtWrk6RJBza6iCb0As/yd6fUgo=; b=Wo2VOdnY6gELABD8i0WlXZWvC6VZljEyqgMbei9SDp594eL8Cj4DrL17/p5vmytP+8 P/xYfGu5g/LaK1btYWYmWvxBXONPlhabWVIcl60G1/PBBFe3QJ2m+MivLnD6IUSNwHkd kGsjE07tuSOXjzt7JJXbGU+Gn8rfBqP2fMdfofMQXUmyt8ZaQQfTUb+xtU6FDM9+Tunt qa7EeohCIYb7LN21iSJVy4jlS4htu56+L/gGi0q60WsQcnmm2I85QfWDiCb1Sm4a5qLv u3kkPmx67KOWlmDnllW0eyoMRmqj/hCDqe5PdAfHRX9FOJIo1uJx7Rk6YddLamR87+KO Yw1Q== X-Gm-Message-State: APjAAAWyG5pjdgWiF56ZuT1sKU5c3y/58KInr1ZAXSGnS5BLvFkxH3S6 55fv5b8Dr4k4n6NT0iNwxALQBnC/CXlzO1T97KrO2g== X-Google-Smtp-Source: APXvYqwYF1WaAk9C4OiU53ZpKev9OrZ5kbc2ioF/WzC/JpSTTQ5o/9fQklMwBHUhouJOey/Iof5F+QMZKSQ84u8PmxQ= X-Received: by 2002:ac8:1e13:: with SMTP id n19mr22770748qtl.384.1575849238618; Sun, 08 Dec 2019 15:53:58 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> <20191206123936.GP72330@Space.Net> In-Reply-To: From: Jen Linkova Date: Mon, 9 Dec 2019 10:53:46 +1100 Message-ID: To: Philip Homburg Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2019 23:54:01 -0000 On Sat, Dec 7, 2019 at 1:10 AM Philip Homburg wrote: > >"number of IPv4 addresses in the pool" comes to mind. > > > >Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large > >enough subnet to cover 100% of all expected hosts if 20% will do? Exactly. > With a few exceptions, just about any DHCP pool I come across these > days is using RFC 1918. > > Are you running out of RFC 1918 addresses in your pool? Yes, I am. I've run out of private addresses. So just deploying NAT64 and giving IPv4 address to all devices by default does not solve my problem, as all those devices will be consuming IPv4 addresses, despite the fact that >80% of those devices would work just fine w/o IPv4. -- SY, Jen Linkova aka Furry From nobody Sun Dec 8 16:01:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468841200FD for ; Sun, 8 Dec 2019 16:01:23 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJZOQuipbskN for ; Sun, 8 Dec 2019 16:01:22 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010CE12002F for ; Sun, 8 Dec 2019 16:01:21 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id o18so2007310qvf.1 for ; Sun, 08 Dec 2019 16:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1Tj0ETLwxzVJWBocu9W2zzVsYQeLGgv7dKAwHGFWW7Y=; b=nQ73yLyI5XcvT7iXMSZhQR5Vi3gG46eO5fy3U2/ITB2U0TPfBFUva4mOwBzjnYern3 3ctjuEuwoScpY/5m9vjt8GvjXcWajXPUNUv+BSGOp27HfvpJLDoUQ7PYuEjZQkT/1S+C +Fgpkh4c0rqncOW3/urVWAEL7k4UYT3vVLav0mcG+KIq4VJpdmLXmJmdvxIyEsmlABjI CyQhdu+8/FMMl+R7O6cQAOKw+HP+zmWIadEq2ZCbda/4DUySB7zO5gKZv07vexixmv9d 9sYMPhvwyv8LTbl1ACqHR3zgcNbdeDIDxyX/GRFtQk44oT/me0uSPzbpp45CajFsKcLs EVXA== 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=1Tj0ETLwxzVJWBocu9W2zzVsYQeLGgv7dKAwHGFWW7Y=; b=AfPfxo7ldRUkgUt/xR4a4TF1ouorBs7btYzQqQW3ETia1PYgRRJmMAq9xejT1You0B j1nRyxeSS1o/GDdwlVS5jb5gIjPj1UbdUGR9tSw2jqjguvwZXvDfkbYvO1oDh6GXGPDS nnNKdNnjlvGSY0715m2/2bHn2GYAHn3OSDiPIdVU6S/hbnagV2WWerWS6ZRlCOof+LsO YQcjQliQjUPVOcRQ9iSXQaenNf50shw0CeTYkv+agYliiHGqfsd28ZBiL+w+LFBN6Ppo lqVnO4fN3MUkDYpTy9apeDMsu5UPYriQmV3HKrU3UPsAAJgaAS1CfML8Eo5stA59HEie r0rg== X-Gm-Message-State: APjAAAXJqfN6YMQN729aysBaT8NlsiujSXNKckPiO25Pe4AfOqbfaQt9 FdRUFpHXxEgyugS2RcpzanpmthY6+PooT+vHm6CZDw== X-Google-Smtp-Source: APXvYqwVtenOPRM2J6jRWlx3Z74410Rf7XbnV/XQE0xBva2cIH9voOMTWbQoSMXyeaq21QCpxmqJLctJH5rws8JNPXo= X-Received: by 2002:ad4:496f:: with SMTP id p15mr21170694qvy.191.1575849680729; Sun, 08 Dec 2019 16:01:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Mon, 9 Dec 2019 11:01:08 +1100 Message-ID: To: Ted Lemon Cc: Philip Homburg , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 00:01:23 -0000 On Sat, Dec 7, 2019 at 1:31 AM Ted Lemon wrote: > I really feel like there is some point-missing going on here. It is trivi= al to make this feature only activate for clients that support it. If that = is done, then there is no reason to assign an address at all. The offer doe= sn=E2=80=99t even need to include that option. So any discussion of what ad= dress to send is irrelevant and unnecessary. The goal is that whatever the server does, it should be able to distinguish it from any failure scenarios and stop asking. That's the reason why we are not suggesting that the server should just ignore requests from the clients if the clients sends the option. The positive signal 'I understand the option and this network is offering IPv6-only service'. Is there any way to do it w/o sending an OFFER back? > > > On Dec 6, 2019, at 06:10, Philip Homburg w= rote: > > > > =EF=BB=BF > >> > >> "number of IPv4 addresses in the pool" comes to mind. > >> > >> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a la= rge > >> enough subnet to cover 100% of all expected hosts if 20% will do? > >> > >> IPv4 seems to be somewhat in short supply these days. > > > > With a few exceptions, just about any DHCP pool I come across these > > days is using RFC 1918. > > > > Are you running out of RFC 1918 addresses in your pool? Or is the setup > > that you give publicly routable IPv4 addresses to all dual stack hosts > > and want to only put hosts that support NAT64 behind NAT? > > > > In that case, what's the rational for providing dual stack hosts with p= ublic > > IPv4 addresses? > > > > > > _______________________________________________ > > 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 SY, Jen Linkova aka Furry From nobody Sun Dec 8 16:47:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1748F12007C for ; Sun, 8 Dec 2019 16:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MABGHUCYApG1 for ; Sun, 8 Dec 2019 16:47:37 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47F8120090 for ; Sun, 8 Dec 2019 16:47:37 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id bd4so5055082plb.8 for ; Sun, 08 Dec 2019 16:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1bPc4kRwGSZkinozw/p/fWGztepe9GFXAb4Ugj9/lXI=; b=JN2H0GzYysyxSwTyZJuqNb5QwlsnxtwD1fMikpX5KIO/L66H3PyJUts7E0n03xB1fm c5S45mDEJCUHx3lk57yLrZhXX3/JZzh7TvDuhILVTlXWSoeGm4hsgSyXJT7SZrPi2U2p 6gMBlGCueyozcorjBCOaSfrDAuz9uINCPt9S7ZGN6zVZjDVnJwHR1R3y9Z+uG+XOBsUF S20Ua6P6huf/zKl8Gnm8FMiiqjC0CJGNpY04nUyhjfCU4zU4Jt2adEL5F+QKBNAn9hYU +7rJcCJUupg3+UMuWeZTz0/DMS4UVWOjtH+7atAFYGzZhTTWVqqZoSHENczhfTqu9lmd Uqpg== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=1bPc4kRwGSZkinozw/p/fWGztepe9GFXAb4Ugj9/lXI=; b=jsnUg3AePKR/XQxWsa+TLjFcISqqDtAna4qAUAI+o42K3T92AhMAjq+FrUfojqqQPx OAQ/5JdKBmGGDnt7MpKPOzQ6yUNkowiY9rGRpp1UTn4WTYfNbmR7mh3q4MSOjHR3Jwe8 P/cjTuWEIO6abIjzShzU872OmhIhABOZS6hZ4NWH21LSQNGjHweVqRyIriS2SLTWCTY2 fCI3jfaJ4qJBcmDw3IGIHY24Wl4PKBRosntabhyZqlPaMM1prUkfq72+auxyBhJZ8JRj HQwy3sRkruvtnw9fKcDOKS6jwrczUQjPDAkFNY5F/JiUqjUXWtCOroAjeJWS11ABlhMg 25gw== X-Gm-Message-State: APjAAAWSzVg4PQau38o4N8JKHEqoPQ8t8u1iPw0C+ex1ONLmwoYD94ol dQJJLAWHZ9Y5ulhsYgIvnTveag== X-Google-Smtp-Source: APXvYqxn7wXl38NVyOCMLEQwhMbvmA58HoVP8tp2tlqGbvX78cPl0GzqprUQ1whMaEmwtqjLrmwTsA== X-Received: by 2002:a17:902:8541:: with SMTP id d1mr27393625plo.57.1575852457150; Sun, 08 Dec 2019 16:47:37 -0800 (PST) Received: from [10.20.3.126] (ip-64-134-236-149.public.wayport.net. [64.134.236.149]) by smtp.gmail.com with ESMTPSA id t8sm25781676pfq.92.2019.12.08.16.47.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Dec 2019 16:47:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 8 Dec 2019 16:47:34 -0800 Message-Id: <2A5D6B07-FD0E-49AB-BD0B-2C8B6500C52E@fugue.com> References: Cc: Philip Homburg , V6 Ops List In-Reply-To: To: Jen Linkova X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 00:47:40 -0000 If the client lists the option in the parameter request list, then the serve= r knows it supports it. It can then send back a dhcpoffer with no address, k= nowing the client will do the right thing. I don=E2=80=99t think there is a way to shut the client up if it does not su= pport the new behavior.=20 > On Dec 8, 2019, at 16:01, Jen Linkova wrote: >=20 > =EF=BB=BFOn Sat, Dec 7, 2019 at 1:31 AM Ted Lemon wrote= : >> I really feel like there is some point-missing going on here. It is trivi= al to make this feature only activate for clients that support it. If that i= s done, then there is no reason to assign an address at all. The offer doesn= =E2=80=99t even need to include that option. So any discussion of what addre= ss to send is irrelevant and unnecessary. >=20 > The goal is that whatever the server does, it should be able to > distinguish it from any failure scenarios and stop asking. That's the > reason why we are not suggesting that > the server should just ignore requests from the clients if the clients > sends the option. The positive signal 'I understand the option and > this network is offering IPv6-only service'. Is there any way to do it > w/o sending an OFFER back? >=20 >>=20 >>>> On Dec 6, 2019, at 06:10, Philip Homburg w= rote: >>>=20 >>> =EF=BB=BF >>>>=20 >>>> "number of IPv4 addresses in the pool" comes to mind. >>>>=20 >>>> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a lar= ge >>>> enough subnet to cover 100% of all expected hosts if 20% will do? >>>>=20 >>>> IPv4 seems to be somewhat in short supply these days. >>>=20 >>> With a few exceptions, just about any DHCP pool I come across these >>> days is using RFC 1918. >>>=20 >>> Are you running out of RFC 1918 addresses in your pool? Or is the setup >>> that you give publicly routable IPv4 addresses to all dual stack hosts >>> and want to only put hosts that support NAT64 behind NAT? >>>=20 >>> In that case, what's the rational for providing dual stack hosts with pu= blic >>> IPv4 addresses? >>>=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 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry From nobody Sun Dec 8 16:54:20 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F01200FD; Sun, 8 Dec 2019 16:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-MD8axplnnz; Sun, 8 Dec 2019 16:54:10 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA4612007C; Sun, 8 Dec 2019 16:54:10 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id t17so7253484qtr.7; Sun, 08 Dec 2019 16:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=unmnH3dZDJPTWO/R7OQTMWW+3RUzttXb0qIPi5xlNvA=; b=bG8AZtsgZq0WJcH9zMGLvYV3zcccnZspH4Mi/o/KME4DRUAeRXY+CTJyFIAXFOkMwR ndXBfUOLlLp9LHFxoHw+K08A30uAj+mRvtRa5jl8fPSwJWOJZYhksKlQ2a3xvxfsJKHD 4AFhWFFpMSQ6hvJ3Z3Tfn4RULeI8kR5Hy8YtbikL9hJRRjn69EJ/cFbIOs3dPBk5h5LF 9i07ysZnJsq7jL5FBMmcirkGSNYvebvi+cdQsciXGtnAhRz6H0fG9KjzjJ6os1kNiJI0 yUMwuGrHUj2fU4NKvyMsko4GT0vpD6cVzatcBil9SZyzA8gfaF1ZnshxUA30XMNG3YLR Pgig== 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=unmnH3dZDJPTWO/R7OQTMWW+3RUzttXb0qIPi5xlNvA=; b=jMwOLcATIH8gX75HIQ2Bey5Hi3xm2r4GKeEh3fWOaCIQcNJHDxxtOTvL/lcoFZ2Qji 3lbmRYJCrm7kWDzaO8jjCuMv4aEg1hoeF3CcTsv4epOvpdml7euuhxK2jn3PN/ZM7j2H wW+rMQfIzKTDNt/LBm84UOxm5edzCct/WXbprqybJoLMCrnbLJTzpGM0a6xny6h5E1T7 X5YAF3qzBw0B0HRtTupkJDJnRl+KVlBu+KM/7zfEl3PwbKkBAqLOCPkSW1+W78DU/fDb RJLtMVyI16XS618S6qScfxikNLMKcgikbQ/SvtS6Sf6UitXsX1h2kejUneXctyJS21Ra phdw== X-Gm-Message-State: APjAAAX6GchiTezkQCyfR1IYxcPcsKyDX2GFSX8EunJtJnzadbmrdy8M HzPSWEV9MtaSgkobSmd8SXHkJa7bmSmuFP/IVws= X-Google-Smtp-Source: APXvYqw6it9paIDEp2j2wRqiX9/xCGAwYMlzRdX6vutQKmd66A8mC0UuPIxN0SSCe6FVt+ez1r5EDpmgyEIfiG0faSo= X-Received: by 2002:ac8:6f75:: with SMTP id u21mr23492983qtv.52.1575852849138; Sun, 08 Dec 2019 16:54:09 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Jen Linkova Date: Mon, 9 Dec 2019 11:53:57 +1100 Message-ID: To: "Bernie Volz (volz)" Cc: Lorenzo Colitti , Tomek Mrugalski , V6 Ops List , "draft-link-dhc-v6only@ietf.org" , "dhcwg@ietf.org" , Michael Richardson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 00:54:12 -0000 On Sat, Dec 7, 2019 at 1:59 AM Bernie Volz (volz) wrote: > I agree with Lorenzo. Keep it simple (see previous email that there reall= y should be no work on the DHCP servers to support this capability). > > Yes, you could reserve an address, but I don=E2=80=99t see that as requir= ed. Note that I had suggested this to the authors before the draft was publ= ished as an optimization; I don=E2=80=99t think it should be the norm. And = with many servers, you could probably just do this via configuration (i.e.,= if PRL contains =E2=80=9CIPv6-Only=E2=80=9D option, override the client id= entity with a fixed unique name, add a fixed address / reservation for that= unique name). I'm fine with it. I'll remove the reference to a dedicated address to retur= n. So just to summarise the discussion: we have a number of options on the tab= le: a) let server just return *an* address from the pool, assuming that as the host would not accept the offer anyway, the address will be made available again soon; pros: --- no changes on the server side; --- it would look normal to smart middle boxes cons: --- might lead to higher pool utilisation b) return some bogus address (0.0.0.0 or smth else) pros: --- client would not be able to assign it (hmm..theoretically) --- optimized pool usage cons: --- requires changes on the server --- might trigger unexpected behaviour on smart middle boxes (=3D=3D> slowing down the adoption) c) do not offer anything, do smth esle instead (what exactly?) After writing it down like that I do agree that we shall probably choose a)= ;) > From: v6ops On Behalf Of Lorenzo Colitti > Sent: Friday, December 6, 2019 2:21 AM > To: Jen Linkova ; Tomek Mrugalski > Cc: V6 Ops List ; draft-link-dhc-v6only@ietf.org; dhcwg@i= etf.org; Michael Richardson > Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option > > > > On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova wrote: > > "If the pool is explicitly configured with a dedicated IPv4 > address to be returned to IPv6-only capable clients the server MUST > specify that address as the client's network address and MUST NOT > verify its uniqueness. > > > > That seems difficult to implement on the server. Why not just return a no= rmal OFFER from the pool? That way, if something unexpected happens and the= client sends a DHCPREQUEST for it, the server can hand it out as normal. > > > > The alternative is risky. If the server uses a bogus OFFER value, and som= e client requests it and the server hands it out, that creates the possibil= ity for misconfiguration or bugs to create really bad outcomes where multip= le hosts have the same IP address, or some things on the network (e.g., sno= oping switches) think that multiple hosts have the same IP address. +Tomek = Mrugalski any thoughts on whether this can be implemented easily and reliab= ly on the server side? --=20 SY, Jen Linkova aka Furry From nobody Sun Dec 8 17:48:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D481200CC; Sun, 8 Dec 2019 17:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGrbqc1I_eKw; Sun, 8 Dec 2019 17:48:00 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D5312007C; Sun, 8 Dec 2019 17:48:00 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id g15so11677641qka.8; Sun, 08 Dec 2019 17:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oYnWaUoZzty5Inf6hsSqeDCfitix0GWLkCyFEkn3oEE=; b=j3lud/0+3UhCZ9p7l89tywmF7yjGGTT4Qq9KewwGzc0kao8ed16yyLCRF4nlopM5l5 /PTxc4rzeCMo/27QKbJbeDWQ0HTw25juLwNO9HxH3OGijni/YC1OBTfmKhewhiobzJ/6 vasxarzN6T7JiKWE0QvspRhWJPwOAjc0GgHwXkfgcL+sXDnSs3OT3m5J5fFBML9w8y0x a5QsupztNNkym8zgYfXGq82botUXrpoHEuK+gdKq+CqovERFI1KWYMVUFjYuN9iEXCgP 731yuKk8mRT7xCmcGqeMF70IysWLncM/4Yffr8OoQdyzjzNu0G4uo0furSiLif0BLDdx 94/w== 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=oYnWaUoZzty5Inf6hsSqeDCfitix0GWLkCyFEkn3oEE=; b=iyECYi5+GzFRKlbOXOJaNcL5iM1Qhwbe0tw1ElgdTFWAEzP3z3TQKkS7WR3BQNKX/8 st4kZOSd9+tXNeOZW/W51OiC6rWskgOCsGOJZ3SBr8N/L/Ll7ffURvMjsJaVkmcjZHJo RUsijF15XbWYvsUqhxdUa2G+ancj0DZK/b1jLoLqeb9p5uMgTboizGxlBk+Wcx1ooRb7 MdOG9yJHOlom2AuFi6aFFbuap3onJg7Osh7OKf5Tw/HM7eZPTg3StnN30RouimUMc+1c dHS5pNPS0/pzDmglEurBj6Db3pQHa8VpUeffGjyrcEu1LF9HabfO1zW+ZyLKTI8sSfAK r4+A== X-Gm-Message-State: APjAAAWiWbL267zeNFgrBcXvErNkzG5g++97pWVAZOCwDChWM6f/SDMN KlajCuVsbwJnI/Oq1mntTvw4ZKK9NkxN41JGbJsvGQ== X-Google-Smtp-Source: APXvYqzkfF2NhyMiMorVwFKbL2zBfsoWG4C09AmdGDs2qVTsGis9q63v9FMyp5mVxfW6u/zFoS9CNMii3NBSjpByiaI= X-Received: by 2002:a37:9fce:: with SMTP id i197mr23943514qke.466.1575856079229; Sun, 08 Dec 2019 17:47:59 -0800 (PST) MIME-Version: 1.0 References: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> In-Reply-To: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> From: Jen Linkova Date: Mon, 9 Dec 2019 12:47:47 +1100 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 01:48:02 -0000 On Sat, Dec 7, 2019 at 3:02 AM Ted Lemon wrote: >> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER = and always include an address because you never know how intermediate devic= es that may be "snooping" this traffic will handle this; for example, the i= ntermediate device might drop what it feels is an invalid packet. > > This is definitely not an issue, though, because the network operator is = choosing to deploy this. They can be responsible for ensuring correct beha= vior if there are any middleboxes intercepting the DHCPv4 traffic and doing= stuff with it. Expecting this to Just Work with no infrastructure change= s seems unnecessary. The question is: how massive those infrastructure changes are and what's the failure scenarios are expected. We might impede or even completely prevent the adoption if the entrance barrier is too high. Also in many cases people operating services (like DHCP) are not the same people who are looking after the network infrastructure. I see a big difference between 'incrementally enabling smth on clients and servers' and 'getting switching and WiFi vendors involved and upgrade the network infrastructure - which means moths or years of delay, not mentioning non-obvious failure scenarios, when only some clients are connected to way-too-smart-boxes'. If we can make it transparent to the switching infrastructure we probably should. -- SY, Jen Linkova aka Furry From nobody Sun Dec 8 17:53:02 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53F712007C for ; Sun, 8 Dec 2019 17:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 u2yubJTcA5zO for ; Sun, 8 Dec 2019 17:52:54 -0800 (PST) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D5F1200CD for ; Sun, 8 Dec 2019 17:52:54 -0800 (PST) Received: by mail-pl1-x642.google.com with SMTP id k20so5095915pll.13 for ; Sun, 08 Dec 2019 17:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=F9F/2h/HJlYX++4fyWX9F9/+AsL28rtcHOBj/wjy3qc=; b=H3g3IWosQjECSGpw1i0bVwLOvbFLMgQuNGI3p6Q2Bbnklt/Ur9s6BdtBfYNk8qvavm Qjl1U5RmiA0ZUK8+IC3NzvdZsXTFvNnCcuP2NL5ICJWYKmEu6E6IICxXtAWHz22ItLdM caDuXoM3pRVigFojOK2ndfsc408t+yDoEfN33PEbT9IBqTlZWdOihT4vsrigmayCNkc5 IFxA73xGkZuTkxoIWl5RGTtlXf02muOscBlaGajsqZ558b4+MLe37iOl4N+totZNxjrx +CvwP4TfjkFuZZE0gjNkHk/R9s8SUcRpoHv86xQyatMPSN/bF9AcWHlT+K/yVo2GS94V Gm6g== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=F9F/2h/HJlYX++4fyWX9F9/+AsL28rtcHOBj/wjy3qc=; b=ad0EwDjeyG7kpfNKRRGK5LBWGADxmx6bU5stDoxubGNMFlrBoCRShCERc4oh0rKX7U Q0Cefw0DRq1mvGV0tmHp55M3fhptCRULOOdCq5KusAx86pXy3C4rAcbY31otIgAtKlO5 TzuCNBas2ts3LyBapP7PRLElTdnCB90fX5RQ/Sde+oaIG1ngxtxjdij0eAM0NEpdI6uZ RetRRITMgJTCde90+eA1i3r5XixiZpwpSHFLkT6O3f9EY64oqjuR2wQBJXYlmv4KrG2m X6hO2FSND7dZ7NSazMogrQCPYEZyE5Kl8ymCSW8Ztc+QbVNToOS5h1d2/kC0RW6Rpmoi hiRA== X-Gm-Message-State: APjAAAVFK1xTagu18h+7/eWejffDEjK3R8oylE7jNC4k/TvknMgJCPHE agXDO9uCV+VE4rh8zn+eJ4Pw1E/eXWsDlA== X-Google-Smtp-Source: APXvYqy2ivH5conPXNt2PYr+YF9A+VcwsAEitlFuFFhILpZXP/VneMZex2mE2vDq4acjqhVqwe1JTw== X-Received: by 2002:a17:902:7448:: with SMTP id e8mr25288844plt.299.1575856373587; Sun, 08 Dec 2019 17:52:53 -0800 (PST) Received: from [10.20.3.126] (ip-64-134-236-149.public.wayport.net. [64.134.236.149]) by smtp.gmail.com with ESMTPSA id p17sm23254510pfn.31.2019.12.08.17.52.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Dec 2019 17:52:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 8 Dec 2019 17:52:52 -0800 Message-Id: <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.com> References: Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "v6ops@ietf.org" In-Reply-To: To: Jen Linkova X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 01:52:57 -0000 We=E2=80=99ve always assumed that the highest possible entry barrier is chan= ges on the client. I=E2=80=99m not aware of any middleware that wouldn=E2=80= =99t handle this correctly, and apparently Bernie isn=E2=80=99t either. I th= ink this is a non issue. If we can get support in clients, we should be able= to deploy.=20 > On Dec 8, 2019, at 17:48, Jen Linkova wrote: >=20 > =EF=BB=BFOn Sat, Dec 7, 2019 at 3:02 AM Ted Lemon wrote= : >>> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER a= nd always include an address because you never know how intermediate devices= that may be "snooping" this traffic will handle this; for example, the inte= rmediate device might drop what it feels is an invalid packet. >>=20 >> This is definitely not an issue, though, because the network operator is c= hoosing to deploy this. They can be responsible for ensuring correct behavi= or if there are any middleboxes intercepting the DHCPv4 traffic and doing st= uff with it. Expecting this to Just Work with no infrastructure changes se= ems unnecessary. >=20 > The question is: how massive those infrastructure changes are and > what's the failure scenarios are expected. We might impede or even > completely prevent the adoption if the entrance barrier is too high. > Also in many cases people operating services (like DHCP) are not the > same people who are looking after the network infrastructure. >=20 > I see a big difference between 'incrementally enabling smth on clients > and servers' and 'getting switching and WiFi vendors involved and > upgrade the network infrastructure - which means moths or years of > delay, not mentioning non-obvious failure scenarios, when only some > clients are connected to way-too-smart-boxes'. > If we can make it transparent to the switching infrastructure we > probably should. > -- > SY, Jen Linkova aka Furry From nobody Sun Dec 8 18:27:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7760912084A; Sun, 8 Dec 2019 18:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=edhPxjwC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QOCZnULV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFWb-B5Xc5Rq; Sun, 8 Dec 2019 18:27:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DD5120144; Sun, 8 Dec 2019 18:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3108; q=dns/txt; s=iport; t=1575858420; x=1577068020; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hwwjyc8PjuXDdu9oH0VhMWDNFaVPApXAqkMT9hT18Y8=; b=edhPxjwCDIVlMaZVxQJYIqS5R70Aj1t8a0B8F6RDpIFAAe4dhf+UwPOZ Q0Rn8UMV88qynHZsT1HZt76E31SdM9yVaSKvknvMDHyOlFtSiFN+J60zK ZRGhMYZLzRWKlJ6dmbB/WCmkZyD5oJQr/UFJ3Dz5y4vxuHCmiMNarNFcu A=; IronPort-PHdr: =?us-ascii?q?9a23=3A5FAp3RwrliS7KA/XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1HsmBG2XwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfBQCXr+1d/5hdJa1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BS1AFgUQgBAsqCoNrg0YDiwOCX4lbjiqCUgNUCQEBAQwBAS0?= =?us-ascii?q?CAQGEQAIXgX4kOBMCAw0BAQQBAQECAQUEbYU3DIVSAQEBAQIBEhERDAEBNwE?= =?us-ascii?q?ECwIBBgIOCgICJgICAh8RFRACBA4FIoMAgkcDDiABAo8VkGQCgTiIYXWBMoJ?= =?us-ascii?q?+AQEFhRoNC4IXCYEOKIwYGoIAgTgggkw+ghuCLoMQMoIsjTU0gj6dRC9DCoI?= =?us-ascii?q?ukUiEHhuaMpklj1ACBAIEBQIOAQEFgWkigVhwFTsqAYJBUBEUjGYMF4NQilN?= =?us-ascii?q?0gSiMYQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,294,1571702400"; d="scan'208";a="592046440" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 02:26:59 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xB92Qxgn001534 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 02:26:59 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Dec 2019 20:26:58 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Dec 2019 21:26:57 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 8 Dec 2019 20:26:57 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jSlOG7KXAu0H5ABiottO41cOOd8XaMmtWtahrmA6iT7D98HwUq2TouqbXjAdwXR78cX7J4JdPIGuNZKzTksG1q6JaBKYSZRM66aCIrHQlo+gA55Kvry0nljOLqSi+JHg/x1bJziHsa6EJOjWdFMaMynFnxhFnDmKR3/OKLBHoPKuW85vlrnYqE5+Z2Uak2cpwWk1Ve3sbr5Y4ReGFZvycYxKoBEygKtVj9ERdK4Uq+S3Szr0YXnvDC/Q+09nTbCafSwJ7hWgkb5W4BV+6va4Kt45v38WG4gohITPBhO6b6+z3kU/UEexpBlUP+q4pEpKeGL+x6desDVLBVtIFI0rDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hwwjyc8PjuXDdu9oH0VhMWDNFaVPApXAqkMT9hT18Y8=; b=fNaPMAJ//TJB0fPvA+M+Zdaq2vNpr3ueor1k0soNxTREQeNoU23hmBMYDaaf2GqYaBd4a0VKhfknmYwInsmgRJLA+15MvlrXtK/18nc3OvJ058NT9uSslB3vxbGgF0qGK3EItTweoX92Fy7RDwYgAnM4WP1udYhn3mz1CMDFoNBIzB/vxvYaBiuP/Pyt5wIxXzp4ounwKutoUaPQFns2kxZuCwFVnTlnsHCleTunix5Ex4F06+7gl34fLhAW63acqBWLjvHbFt8W/iLx57WuoPRJLpkLi2lZm3clnwPMA3jI/5XP7WUOXm1c6FNLZLmubLth6r+DKXjVIM20kEl2iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hwwjyc8PjuXDdu9oH0VhMWDNFaVPApXAqkMT9hT18Y8=; b=QOCZnULVFZJ3/sFkjlnodE9XAXbLswefuvJKQt/804GIsPcUOpRKc/JodmhS6DL7vY7aMQEv7zgIoZXEl2ZJk1AkzYbam7zGKgQDyMqmldQbaWdNDr4Qvq0M+K/3w3tTLPkxHl0zbP2AfjRJlZVjk/e0cgPq2J/ixmdVVpjHs+c= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3771.namprd11.prod.outlook.com (20.178.231.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Mon, 9 Dec 2019 02:26:57 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 02:26:57 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Jen Linkova , "dhcwg@ietf.org" , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrEHbgQve9DKh2EKQEqgwr7Y10qetK3KQgAAZCACAA8hSgIAAAWwAgAAJhY4= Date: Mon, 9 Dec 2019 02:26:56 +0000 Message-ID: <3DCA2FEC-14B2-4B6F-B491-A93BCF4A90FB@cisco.com> References: , <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.com> In-Reply-To: <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.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=volz@cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef9e782d-2097-4ecf-817b-08d77c4f4362 x-ms-traffictypediagnostic: DM6PR11MB3771: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(366004)(136003)(199004)(189003)(53546011)(6512007)(186003)(6506007)(102836004)(26005)(2616005)(229853002)(305945005)(6916009)(4326008)(36756003)(8936002)(71190400001)(81166006)(71200400001)(8676002)(81156014)(2906002)(66446008)(76116006)(33656002)(91956017)(66476007)(99286004)(5660300002)(66946007)(76176011)(54906003)(6486002)(316002)(86362001)(64756008)(66556008)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3771; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2f+CTGPYLv5F9uXrZO8v/HkrIJatYmbK0tXC4M5Z6mb6DvqJCbkKOldjlHagsoXR8ncOx5QcwRVGQieCrSY50M7RJLoYWiRMilLiHKHSsaJBGiYmkrkbHvj5TgKMmfmWlp/FluxG0S3oGvtOrkg3wCmoFhs/GdkDOhjOKm42w9n48GlqdV/nlJF1xC9ziCRkqLgtwG4EHDPRceuQKcFWSgjX+cziMYw5RktOg3ttmlTIEu5xAlCuA0PkZfJ0KjcnH4Uz2Y9h3AdVO12SM7ITIdQnjSpSE+wILHxvlDCBnt/Zzh+0jLzBjrr777avzO+z8vhy10jL+ewSgDvZJ5vNmsYF3hMboNaUDglWrRErTEzsvEYsM8mFgwO1h/U7KRXpyEsTUA0bYdkOf0AJdeAIj+gFCl9QgV9e/qDeav+yhBuJhMgBuxC8dHpeEIhoLUKG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef9e782d-2097-4ecf-817b-08d77c4f4362 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 02:26:56.9075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XSfLMYe9+BuY2Y8QyaSpBSTTZdsIfI4DZzJx/mmMhymsBgIt+Ldrp0mwfZyvpT06 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3771 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 02:27:04 -0000 SeKAmW0gd2l0aCBKZW4gdG8gZ28gd2l0aCBvcHRpb24gQSBpbiBoZXIgbGlzdC4gU2FmZXN0IGFu ZCByZXF1aXJlcyBmZXdlciBjaGFuZ2VzIC8gdGVzdGluZy4NCg0KSSBzYWlkIEkgaGF2ZSBubyBp ZGVhIHdoZXRoZXIgbWlkZGxld2FyZSB3b3VsZCBoYXZlIGFueSBpc3N1ZXMsIHN1cmUg4oCcaSBh bSBub3QgYXdhcmXigJ0g4oCUIGJ1dCBJIGhhdmVu4oCZdCBkb25lIGFueSB0ZXN0aW5nIGFuZCBk b27igJl0IHNlZSBhIG5lZWQgdG8gYXMgb3B0aW9uIGEgaXMgc28gbXVjaCBiZXR0ZXIuDQoNCi0g QmVybmllDQoNCj4gT24gRGVjIDgsIDIwMTksIGF0IDg6NTMgUE0sIFRlZCBMZW1vbiA8bWVsbG9u QGZ1Z3VlLmNvbT4gd3JvdGU6DQo+IA0KPiDvu79XZeKAmXZlIGFsd2F5cyBhc3N1bWVkIHRoYXQg dGhlIGhpZ2hlc3QgcG9zc2libGUgZW50cnkgYmFycmllciBpcyBjaGFuZ2VzIG9uIHRoZSBjbGll bnQuIEnigJltIG5vdCBhd2FyZSBvZiBhbnkgbWlkZGxld2FyZSB0aGF0IHdvdWxkbuKAmXQgaGFu ZGxlIHRoaXMgY29ycmVjdGx5LCBhbmQgYXBwYXJlbnRseSBCZXJuaWUgaXNu4oCZdCBlaXRoZXIu IEkgdGhpbmsgdGhpcyBpcyBhIG5vbiBpc3N1ZS4gSWYgd2UgY2FuIGdldCBzdXBwb3J0IGluIGNs aWVudHMsIHdlIHNob3VsZCBiZSBhYmxlIHRvIGRlcGxveS4gDQo+IA0KPj4gT24gRGVjIDgsIDIw MTksIGF0IDE3OjQ4LCBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPj4g DQo+PiDvu79PbiBTYXQsIERlYyA3LCAyMDE5IGF0IDM6MDIgQU0gVGVkIExlbW9uIDxtZWxsb25A ZnVndWUuY29tPiB3cm90ZToNCj4+Pj4gUGVyc29uYWxseSwgSSB3b3VsZCBOT1QgcmVjb21tZW5k IGJyZWFraW5nIHRoZSBzZW1hbnRpY3Mgb2YgYSBESENQT0ZGRVIgYW5kIGFsd2F5cyBpbmNsdWRl IGFuIGFkZHJlc3MgYmVjYXVzZSB5b3UgbmV2ZXIga25vdyBob3cgaW50ZXJtZWRpYXRlIGRldmlj ZXMgdGhhdCBtYXkgYmUgInNub29waW5nIiB0aGlzIHRyYWZmaWMgd2lsbCBoYW5kbGUgdGhpczsg Zm9yIGV4YW1wbGUsIHRoZSBpbnRlcm1lZGlhdGUgZGV2aWNlIG1pZ2h0IGRyb3Agd2hhdCBpdCBm ZWVscyBpcyBhbiBpbnZhbGlkIHBhY2tldC4NCj4+PiANCj4+PiBUaGlzIGlzIGRlZmluaXRlbHkg bm90IGFuIGlzc3VlLCB0aG91Z2gsIGJlY2F1c2UgdGhlIG5ldHdvcmsgb3BlcmF0b3IgaXMgY2hv b3NpbmcgdG8gZGVwbG95IHRoaXMuICBUaGV5IGNhbiBiZSByZXNwb25zaWJsZSBmb3IgZW5zdXJp bmcgY29ycmVjdCBiZWhhdmlvciBpZiB0aGVyZSBhcmUgYW55IG1pZGRsZWJveGVzIGludGVyY2Vw dGluZyB0aGUgREhDUHY0IHRyYWZmaWMgYW5kIGRvaW5nIHN0dWZmIHdpdGggaXQuICAgRXhwZWN0 aW5nIHRoaXMgdG8gSnVzdCBXb3JrIHdpdGggbm8gaW5mcmFzdHJ1Y3R1cmUgY2hhbmdlcyBzZWVt cyB1bm5lY2Vzc2FyeS4NCj4+IA0KPj4gVGhlIHF1ZXN0aW9uIGlzOiBob3cgbWFzc2l2ZSB0aG9z ZSBpbmZyYXN0cnVjdHVyZSBjaGFuZ2VzIGFyZSBhbmQNCj4+IHdoYXQncyB0aGUgZmFpbHVyZSBz Y2VuYXJpb3MgYXJlIGV4cGVjdGVkLiBXZSBtaWdodCBpbXBlZGUgb3IgZXZlbg0KPj4gY29tcGxl dGVseSBwcmV2ZW50IHRoZSBhZG9wdGlvbiBpZiB0aGUgZW50cmFuY2UgYmFycmllciBpcyB0b28g aGlnaC4NCj4+IEFsc28gaW4gbWFueSBjYXNlcyBwZW9wbGUgb3BlcmF0aW5nIHNlcnZpY2VzIChs aWtlIERIQ1ApIGFyZSBub3QgdGhlDQo+PiBzYW1lIHBlb3BsZSB3aG8gYXJlIGxvb2tpbmcgYWZ0 ZXIgdGhlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUuDQo+PiANCj4+IEkgc2VlIGEgYmlnIGRpZmZl cmVuY2UgYmV0d2VlbiAnaW5jcmVtZW50YWxseSBlbmFibGluZyBzbXRoIG9uIGNsaWVudHMNCj4+ IGFuZCBzZXJ2ZXJzJyBhbmQgJ2dldHRpbmcgc3dpdGNoaW5nIGFuZCBXaUZpIHZlbmRvcnMgaW52 b2x2ZWQgYW5kDQo+PiB1cGdyYWRlIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIC0gd2hpY2gg bWVhbnMgbW90aHMgb3IgeWVhcnMgb2YNCj4+IGRlbGF5LCBub3QgbWVudGlvbmluZyBub24tb2J2 aW91cyBmYWlsdXJlIHNjZW5hcmlvcywgd2hlbiBvbmx5IHNvbWUNCj4+IGNsaWVudHMgYXJlIGNv bm5lY3RlZCB0byB3YXktdG9vLXNtYXJ0LWJveGVzJy4NCj4+IElmIHdlIGNhbiBtYWtlIGl0IHRy YW5zcGFyZW50IHRvIHRoZSBzd2l0Y2hpbmcgaW5mcmFzdHJ1Y3R1cmUgd2UNCj4+IHByb2JhYmx5 IHNob3VsZC4NCj4+IC0tDQo+PiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Sun Dec 8 20:30:58 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF18C1200CC; Sun, 8 Dec 2019 20:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IS_I6MAWlTX; Sun, 8 Dec 2019 20:30:49 -0800 (PST) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF7412004A; Sun, 8 Dec 2019 20:30:49 -0800 (PST) Received: by mail-qk1-x743.google.com with SMTP id v23so11962146qkg.2; Sun, 08 Dec 2019 20:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bEQLsBB1cHEr54UDaEEI1x2QNSnFFwfTYMAha4OoBtU=; b=q7n8rTU/j4RdHC7bvx2W0w2z/qvvrSdK0gHDOK8omhVem7fgHvbKIuHCJCD2EiZOtT Z8jDNFqwDAIDQcz5iGEMX684by09mxGJP4eNnQxScPm4nFrkhUTcV/VlI1uNjGpN4HpW qUrSJkkWl7CxvTIsb0KqXHYfDCPRqCJW3QsjhiOZHZChiA4bzdSNUK1yAK3SATGgOS/E FHvxe1L2V9Qm9SERZiSu2zCTWV8CwykNC6mGe/zKwaUieZRkKDGblEZQtPtgHjc+rMH0 SYJu5WeTii8jKx+TI8RHhuY2uY6yRzssNIllFpJ+0ZWDq/VW+1qmSeTwRcBQcCLKdiLE EIgw== 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=bEQLsBB1cHEr54UDaEEI1x2QNSnFFwfTYMAha4OoBtU=; b=G+CZPiL4MjA8j0lXAaWOqzX0NpenjwFfVHsbLVyeoeQNJ+UNxHe1h0oBz4cpANvLa3 zxqsTh8l2mwAsnv9J2NUkeKyeCzhs5rONQjfi/p2UDlpUFcpXIQH9KC12fqNdjnhWVP5 usIU3kV/Mr4Du9zyDzn5plgvD7tJDE5kZE9TmUg1OKdb/u+OKGHdbYuEdnwKFYR4gV2C BXv3DMhrzN8Eg34qLWbJfJ2/DbeP4hqVlmyo118ScwhCTVulBCOgPkM1n3avQA3v5i5H 9i6emSS/KlEN7+THqe5kv2Vbo0lo0VD2LV9JMCFp1BjWXLPBOa3wG9ljJ3i3tAyK8Z6o NWmw== X-Gm-Message-State: APjAAAVdCbGV610jUwmX/UNiSkOkpQZZ/22XOjWFzgXt4DiF75xp2POf aN9B3MLkKSJCRyCOq2q99EbiNjp0q5vj4czhJqM= X-Google-Smtp-Source: APXvYqywHWNfCBB4bBkHKCCK81EUH5AISRCHaWslZMtjeII3tPdRwHEeC7raY7F8/EDU5MdWNqi69/1/WX6klYL5kyI= X-Received: by 2002:a37:4841:: with SMTP id v62mr18300783qka.444.1575865848521; Sun, 08 Dec 2019 20:30:48 -0800 (PST) MIME-Version: 1.0 References: <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.com> In-Reply-To: <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.com> From: Jen Linkova Date: Mon, 9 Dec 2019 15:30:37 +1100 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 04:30:51 -0000 On Mon, Dec 9, 2019 at 12:52 PM Ted Lemon wrote: > > We=E2=80=99ve always assumed that the highest possible entry barrier is c= hanges on the client. I'd say it's a barrier between 'now' and '100% adoption'. But it's not a barrier for an incremental deployment. In this case in particular - I'd not expect 100% of devices to support the option, but as many of those devices would not have IPv6-only capability as well, that's fine. So the long tail is acceptable here - that long tail is what we are deploying IPv6-mostly (IPv4-as-a-Service) networks anyway. >I=E2=80=99m not aware of any middleware that wouldn=E2=80=99t handle this = correctly, and apparently Bernie isn=E2=80=99t either. I think this is a no= n issue. If we can get support in clients, we should be able to deploy. To prove existence it's enough to provide a single example. Proving non-existence is much harder and absence of evidence is not evidence of absence. Practically speaking I'd prefer to minimize the risk. While do not know the probability of a smart infrastructure device getting an allergic reaction to abnormal DHCP packet, the potential impact is quite high. I'm not sure what's the impact of returning an address (ex. for making that address unavailable for a short period of time)? > > > On Dec 8, 2019, at 17:48, Jen Linkova wrote: > > > > =EF=BB=BFOn Sat, Dec 7, 2019 at 3:02 AM Ted Lemon wr= ote: > >>> Personally, I would NOT recommend breaking the semantics of a DHCPOFF= ER and always include an address because you never know how intermediate de= vices that may be "snooping" this traffic will handle this; for example, th= e intermediate device might drop what it feels is an invalid packet. > >> > >> This is definitely not an issue, though, because the network operator = is choosing to deploy this. They can be responsible for ensuring correct b= ehavior if there are any middleboxes intercepting the DHCPv4 traffic and do= ing stuff with it. Expecting this to Just Work with no infrastructure cha= nges seems unnecessary. > > > > The question is: how massive those infrastructure changes are and > > what's the failure scenarios are expected. We might impede or even > > completely prevent the adoption if the entrance barrier is too high. > > Also in many cases people operating services (like DHCP) are not the > > same people who are looking after the network infrastructure. > > > > I see a big difference between 'incrementally enabling smth on clients > > and servers' and 'getting switching and WiFi vendors involved and > > upgrade the network infrastructure - which means moths or years of > > delay, not mentioning non-obvious failure scenarios, when only some > > clients are connected to way-too-smart-boxes'. > > If we can make it transparent to the switching infrastructure we > > probably should. > > -- > > SY, Jen Linkova aka Furry --=20 SY, Jen Linkova aka Furry From nobody Sun Dec 8 22:03:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9B0120103 for ; Sun, 8 Dec 2019 22:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ugCSVa_AapWQ for ; Sun, 8 Dec 2019 22:03:41 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3681200E9 for ; Sun, 8 Dec 2019 22:03:41 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id z26so13462330iot.8 for ; Sun, 08 Dec 2019 22:03:41 -0800 (PST) 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=I/ZdrxjcUVUCR02ICzBA2LaIheWWjBZ/5Eacp+v+uv4=; b=p+xsiD+CClbGuTuYHPQpvCQ7PNHj5qK/ok9hR+1ZSztIcFttRd4MdlDiuJYl2rj9nB ch5Ki4fT5TwYR1Ga8ik0XfdRZGEzl6JAbxW3kiqbxCC1zjGZsPpPG7ALpjNgAbH1vi1u IUAkzw+YlO2m96jlyA0b/qeICalGnHs+/ONXWNNw0qPBuH4lHpFLJeRRXGkqjIpdiHqF RXHPMl7glZose50Bpa5u3q9QBqNeLtfB7mc/2MMXSo23Ah3PXFG0WCSRRKNpYUhy10Md xK7jpIzBv7jDAQ8UbydnJJqz0F9/hDcd26KQcDJYWcGldAQ7rcG2b332UTklzdquJ8Jj LRsg== 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=I/ZdrxjcUVUCR02ICzBA2LaIheWWjBZ/5Eacp+v+uv4=; b=K+xSnLtfP1PmTdLqbMxENJN8U0h8BNTd5I16GGg5KN+1kgNJZhB9ihD9uyS5us+BQV 36TAiv9T66j/QP3jn1nSMuR2zUPeuKVvZbT1/dNl5oP4xByHlc8TDICZYJ3EYuhp6Vp+ xHVaX3dDC09pl6/ZzJ0cXZtHXTGkAJO7EHv1w+UawufH/264LtxuA4xe3GONNgUT+5r+ MDVdB+W2yWiudBWq0Ioh9zgRmC8SfD39hkRB7qe6a5z7KzpVYRmSj0Y7q7CR5iEZUKLW L0synFK4ZbsCM34K+ocY7tHQx8CA7Dwnvc1ULsu3jz2ZmODUMgIpSvMGWtEHFZaAULDU z9Mg== X-Gm-Message-State: APjAAAVTPi3NXI/cGfPmdhZyXqlDH8J5/D6L0W0SPTzKa7oWV6k/1BNA JrauZteftn1BcqBkgJP6omiI2N8vo1doJbt55Wd9iA== X-Google-Smtp-Source: APXvYqzRx4MG8ef7wHdV0Mo7IFfS/d0mHF+nDFwb+4gquwlk3juHsnpxJkuwkDGdNd9b7eJpl480UvezQeyjWbBjUPY= X-Received: by 2002:a02:2909:: with SMTP id p9mr25844448jap.59.1575871420030; Sun, 08 Dec 2019 22:03:40 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Lorenzo Colitti Date: Mon, 9 Dec 2019 15:03:27 +0900 Message-ID: To: Jen Linkova Cc: "Bernie Volz (volz)" , Tomek Mrugalski , V6 Ops List , "draft-link-dhc-v6only@ietf.org" , "dhcwg@ietf.org" , Michael Richardson Content-Type: multipart/alternative; boundary="00000000000034602205993f28d7" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 06:03:44 -0000 --00000000000034602205993f28d7 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 9, 2019 at 9:54 AM Jen Linkova wrote: > I'm fine with it. I'll remove the reference to a dedicated address to > return. > So just to summarise the discussion: we have a number of options on the > table: > a) let server just return *an* address from the pool, assuming that as > the host would not accept the offer anyway, the address will be made > available again soon; > pros: > --- no changes on the server side; > --- it would look normal to smart middle boxes > cons: > --- might lead to higher pool utilisation > b) return some bogus address (0.0.0.0 or smth else) > pros: > --- client would not be able to assign it (hmm..theoretically) > --- optimized pool usage > cons: > --- requires changes on the server > --- might trigger unexpected behaviour on smart middle boxes > (==> slowing down the adoption) > > c) do not offer anything, do smth esle instead (what exactly?) > > After writing it down like that I do agree that we shall probably choose > a) ;) > I would change b) "return 0.0.0.0" and add: d) configure a specific address from the pool for all IPv6-only-capable clients pros: --- most efficiently preserves IPv4 addresses. Always works even if all clients ask for an address at the same time. cons: --- requires changes on the server --- client cannot actually get the address, so if it sends a request, things won't go well. In that sense I think b) is a non-starter, and I don't think c) is feasible either: we do need to return something to the client, otherwise it can't know that IPv6-only will work, and I don't think there's anything other than OFFER that the server respond with (I don't think NAK is typically sent in response to DISCOVER). So I think we're down to a) offer a regular address from the pool, and d) offer a bogus address. The draft attempts to do both right now. I wonder if we could leave d) in the text, but make it clear that it's just a possible optimization? --00000000000034602205993f28d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2019 at = 9:54 AM Jen Linkova <furry13@gmail.com> wrote:
I'm = fine with it. I'll remove the reference to a dedicated address to retur= n.
So just to summarise the discussion: we have a number of options on the tab= le:
a) let server just return *an* address from the pool, assuming that as
the host would not accept the offer anyway, the address will be made
available again soon;
=C2=A0 =C2=A0pros:
=C2=A0 =C2=A0 =C2=A0 --- no changes on the server side;
=C2=A0 =C2=A0 =C2=A0 --- it would look normal to smart middle boxes
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- might lead to higher pool utilisation
b) return some bogus address (0.0.0.0 or smth else)
=C2=A0 =C2=A0 pros:
=C2=A0 =C2=A0 =C2=A0 =C2=A0--- client would not be able to assign it (hmm..= theoretically)
=C2=A0 =C2=A0 =C2=A0 --- optimized pool usage
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- requires changes on the server
=C2=A0 =C2=A0 =C2=A0 --- might trigger unexpected behaviour on smart middle= boxes
(=3D=3D> slowing down the adoption)

c) do not offer anything, do smth esle instead (what exactly?)

After writing it down like that I do agree that we shall probably choose a)= ;)

I would change b) "return 0.0.= 0.0" and add:

d) configure a specific address= from the pool for all IPv6-only-capable clients
=C2=A0 =C2=A0 pr= os:
=C2=A0 =C2=A0 =C2=A0 =C2=A0--- most efficiently preserves IPv4 addresses. A= lways works even if all clients ask for an address at the same time.
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- requires changes on the server
=C2= =A0 =C2=A0 =C2=A0 --- client cannot actually get the address, so if it send= s a request, things won't go well.

In that= sense I think b) is a non-starter, and I don't think c) is feasible ei= ther: we do need to return something to the client, otherwise it can't = know that IPv6-only will work, and I don't think there's anything o= ther than OFFER that the server respond with (I don't think NAK is typi= cally sent in response to DISCOVER).

So I think we= 're down to a) offer a regular address from the pool, and d) offer a bo= gus address. The draft attempts to do both right now. I wonder if we could = leave d) in the text, but make it clear that it's just a possible optim= ization?
--00000000000034602205993f28d7-- From nobody Sun Dec 8 22:37:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811AB120074 for ; Sun, 8 Dec 2019 22:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, 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 26s7dt-BIUmz for ; Sun, 8 Dec 2019 22:37:22 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FEB12003F for ; Sun, 8 Dec 2019 22:37:22 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id f6so11731537ilh.9 for ; Sun, 08 Dec 2019 22:37:22 -0800 (PST) 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=eb8w4IFMY49ujso7tH3sPvVOpS4cvQlFjS2hAeiIqxg=; b=DphK66Amtr+uagQRphG6zXa9JvnFrMwJjUJeTB+5IH+UrZ/oYW9kPJe8n+g0lu33VL 7gAgW8jmNDQ1+wC9MTouVZypGsAq5k/uMtWNSyOvXTYekptVDGxW08khpIbxYh6+tMbd ueA+OtyPYDlWXO1LV/1SnjskJOvmXFxraDM5MWFtWJfQWUD2XxN2AgUsBiiQD9JDcpvy FWXzEv3eQQidA0xHDTbPhKouJi+C5MWw4Dd+c+hWiB1tI1FzXngO+bJ8mvM5q+zjkRDx o1I7GUYTY9GkfGQ4YLTRT6VF+GfS9jrlkMDXlrOhEymksZwfmk7Xj2hrwwYErZEeqetp BzFw== 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=eb8w4IFMY49ujso7tH3sPvVOpS4cvQlFjS2hAeiIqxg=; b=uUPAWYmnewAkWLh82TOJmFFua5pLBMFuSR/IOLcTvRyTGCwpAIMJoUOAHEFDD6/bmy YTkJHsOCeKKoPJGIRxVB1OcQc5ivsrBEmBR9bKxoghbSBUzORuDRGaFCRyxLSVWqjw5f y4YHM5hoUp4p37L6cRFWWwmmIKMSe/WwpS+vKairr/KF9MgOqMky5s5i9V4sLmWJHl+x QeWO1nAcnrqjB7PneQQDMVdfnOuzbn4cmT9/6P+bm/WBVsRFk3iQvLQ+FHtRve03yeol FYYX0Ju1eIwMOqzQwmLdhGk85eRY2+iC18f7mf222aXHhSAHCQXcQRBJMbgGNK0bWM9c Z21w== X-Gm-Message-State: APjAAAWUMjikzFZi8e5khXfxRxa7ptvES1sxjJ2Dfe9TbMjSCM9dUJaO 00OcLfUI+/P8R7koizyC9EFbQHzVAOpxp02VoTMRqw== X-Google-Smtp-Source: APXvYqwKqwVVHV8Dyix4+EDLHabe8jtOtXqIiubKD+nJOc7Kve6bL2LPnRcEY9/LWd0NFujTBOtHXxthMPavG8XJGys= X-Received: by 2002:a92:3b10:: with SMTP id i16mr28471420ila.170.1575873441231; Sun, 08 Dec 2019 22:37:21 -0800 (PST) MIME-Version: 1.0 References: <8AD8345C-3098-419D-9B25-73595286A7B2@fugue.com> In-Reply-To: From: Lorenzo Colitti Date: Mon, 9 Dec 2019 15:37:09 +0900 Message-ID: To: Jen Linkova Cc: Ted Lemon , "dhcwg@ietf.org" , "v6ops@ietf.org" , "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary="000000000000ad5a7c05993fa0bc" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 06:37:26 -0000 --000000000000ad5a7c05993fa0bc Content-Type: text/plain; charset="UTF-8" On Mon, Dec 9, 2019 at 1:30 PM Jen Linkova wrote: > Practically speaking I'd prefer to minimize the risk. > While do not know the probability of a smart infrastructure device > getting an allergic reaction to abnormal DHCP packet, the potential > impact is quite high. > +1 > I'm not sure what's the impact of returning an address (ex. for making > that address unavailable for a short period of time)? > The only downside that I can think of is that if you have a thundering herd of devices that come online all at the same time (e.g., power loss and site-wide reboot), the offers handed to the v6only-capable devices, in the brief time they are allocated, can exhaust the pool such that v6only-incapable devices cannot immediately get an address. However, the server can mitigate that in two ways: 1. When issuing an offer, don't reserve the address, or reserve it for a very short time. 2. When issuing an offer to a v6only-capable device, don't reserve the address. If the v6only-capable device then comes back and sends a request (which it shouldn't, unless something very strange happens), then the address may be in use by a v6only-incapable device. In that case, the v6only-capable device will get a nak and can go back to discover. --000000000000ad5a7c05993fa0bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2019 at 1:30 PM Jen Linkova &l= t;furry13@gmail.com> wrote:
=
Practically speakin= g I'd prefer to minimize the risk.
While do not know the probability of a smart infrastructure device
getting an allergic reaction to abnormal DHCP packet, the potential
impact is quite high.

+1
=C2= =A0
I'm not sure= what's the impact of returning an address (ex. for making
that address unavailable for a short period of time)?
=
The only downside that I can think of is that if you have a = thundering herd of devices that come online all at the same time (e.g., pow= er loss and site-wide reboot), the offers handed to the v6only-capable devi= ces, in the brief time they are allocated, can exhaust the pool such that v= 6only-incapable devices cannot immediately get an address. However, the ser= ver can mitigate that in two ways:
  1. When issuing an offer,= don't reserve the address, or reserve it for a very short time.
    2. When issuing an offer to a v6only-capable device, don't reserve the a= ddress. If the v6only-capable device then comes back and sends a request (w= hich it shouldn't, unless something very strange happens), then the add= ress may be in use by a v6only-incapable device. In that case, the v6only-c= apable device will get a nak and can go back to discover.
--000000000000ad5a7c05993fa0bc-- From nobody Sun Dec 8 22:40:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BBE120074 for ; Sun, 8 Dec 2019 22:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 PkFu-BlKhRqj for ; Sun, 8 Dec 2019 22:40:05 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329A01200FF for ; Sun, 8 Dec 2019 22:40:05 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id w13so11775643ilo.1 for ; Sun, 08 Dec 2019 22:40:05 -0800 (PST) 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=H3drQaB9rI5T4aN9NDdhJ+WDdjfE1Ig6nWOFhaA5oZw=; b=CyeYYkvCbEuZZ35FIxw4SvP2V+WI2qk74/YGHDkVHAWPkdW0D7c1c7LfPWEr4OPblq eZfGUalm+qUeDE06BercDPAIIHVtHZYbUYqYT8N/AfUH3/HyZYSKAlbY+DgpbdQjXVvh bIusTHLuBILqSWckEduKV+QUgOwR20a8LcB62CwR3mkJ+Lt58LZZ8j1u+duiyP6cXGFV T7KoyFIsIAxTdRq4jxWSAroX8EGeSJz0J0AlPH798QKkIOKT5IEwt7IAhFb+q1UeAnqv /9Alb2zJu8So80Y6QHcV4rQMF2sK7hF29y3W+WBSb8LtCRDrUgk6CmGa5YLYsrd9RPDY eY6w== 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=H3drQaB9rI5T4aN9NDdhJ+WDdjfE1Ig6nWOFhaA5oZw=; b=HV0Tb6yACnmAXTxBTrtY0ULHF7klQL47Ku+a3gNSq853OjvJccgzkOhPPaQSl2J/Wp qW9cIeGVNXoTExciw6AT98xFmuDCDjwMv8wVYVOUG6nVHwAk3f51Y+6umK0pH7ZeqXGV xTiiyQ7O+azZR4AwsE3JOjRi9B9z+gP4yXmMSm6cRZpf8gp+LqGNQwqV1Sf8bYX7m7PT typN5i7G2ZkWr4VOln7vhlVsXTDl9Ir3WsXgHfRnYFWQTp3fqsNl+qQOyDz08jKcSSgr nfKqpZJky4TvSJXt3NW5SE+G/kWedyeiOb7F3joumdCUYDH0AkqvxOZ49bnbYKehmEsj eL/w== X-Gm-Message-State: APjAAAVa6WcVnr8RbraHEe/Jcw2m82SuaAKyJA2i7CGh9DPiKIR1JxHx hSpPby42tCOYkTpYnuNogaH09X91bbSPzZVmtvqEZw== X-Google-Smtp-Source: APXvYqy6YKxetUe547HCZBCk0rkijuJqErGqBmltGeCmbYvLR/VHRe7PeJIRmdH1unXYQR3Dstcy8obAW1W0lvRTmoA= X-Received: by 2002:a92:8912:: with SMTP id n18mr27206600ild.241.1575873604163; Sun, 08 Dec 2019 22:40:04 -0800 (PST) MIME-Version: 1.0 References: <2A5D6B07-FD0E-49AB-BD0B-2C8B6500C52E@fugue.com> In-Reply-To: <2A5D6B07-FD0E-49AB-BD0B-2C8B6500C52E@fugue.com> From: Lorenzo Colitti Date: Mon, 9 Dec 2019 15:39:52 +0900 Message-ID: To: Ted Lemon Cc: Jen Linkova , V6 Ops List Content-Type: multipart/alternative; boundary="0000000000006394fd05993faa53" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 06:40:08 -0000 --0000000000006394fd05993faa53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted, It sounds like you're arguing that the network should put 0.0.0.0 in the yiaddr field when sending an offer, even if doing so requires more server changes. What I don't understand though, is: why? What is the advantage of putting 0.0.0.0 in the offer? What do those server changes buy us? Cheers, Lorenzo On Mon, Dec 9, 2019 at 9:47 AM Ted Lemon wrote: > If the client lists the option in the parameter request list, then the > server knows it supports it. It can then send back a dhcpoffer with no > address, knowing the client will do the right thing. > > I don=E2=80=99t think there is a way to shut the client up if it does not= support > the new behavior. > > > On Dec 8, 2019, at 16:01, Jen Linkova wrote: > > > > =EF=BB=BFOn Sat, Dec 7, 2019 at 1:31 AM Ted Lemon wr= ote: > >> I really feel like there is some point-missing going on here. It is > trivial to make this feature only activate for clients that support it. I= f > that is done, then there is no reason to assign an address at all. The > offer doesn=E2=80=99t even need to include that option. So any discussion= of what > address to send is irrelevant and unnecessary. > > > > The goal is that whatever the server does, it should be able to > > distinguish it from any failure scenarios and stop asking. That's the > > reason why we are not suggesting that > > the server should just ignore requests from the clients if the clients > > sends the option. The positive signal 'I understand the option and > > this network is offering IPv6-only service'. Is there any way to do it > > w/o sending an OFFER back? > > > >> > >>>> On Dec 6, 2019, at 06:10, Philip Homburg > wrote: > >>> > >>> =EF=BB=BF > >>>> > >>>> "number of IPv4 addresses in the pool" comes to mind. > >>>> > >>>> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a > large > >>>> enough subnet to cover 100% of all expected hosts if 20% will do? > >>>> > >>>> IPv4 seems to be somewhat in short supply these days. > >>> > >>> With a few exceptions, just about any DHCP pool I come across these > >>> days is using RFC 1918. > >>> > >>> Are you running out of RFC 1918 addresses in your pool? Or is the set= up > >>> that you give publicly routable IPv4 addresses to all dual stack host= s > >>> and want to only put hosts that support NAT64 behind NAT? > >>> > >>> In that case, what's the rational for providing dual stack hosts with > public > >>> IPv4 addresses? > >>> > >>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000006394fd05993faa53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted,

It sounds like you're arguing = that the network should put 0.0.0.0 in the yiaddr field when sending an off= er, even if doing so requires more server changes. What I don't underst= and though, is: why? What is the advantage of putting 0.0.0.0 in the offer?= What do those server changes buy us?

Cheers,
Lorenzo

On Mon, Dec 9, 2019 at 9:47 AM Ted Lemon <mellon@fugue.com> wrote:
If the client lists the option in = the parameter request list, then the server knows it supports it. It can th= en send back a dhcpoffer with no address, knowing the client will do the ri= ght thing.

I don=E2=80=99t think there is a way to shut the client up if it does not s= upport the new behavior.

> On Dec 8, 2019, at 16:01, Jen Linkova <furry13@gmail.com> wrote:
>
> =EF=BB=BFOn Sat, Dec 7, 2019 at 1:31 AM Ted Lemon <mellon@fugue.com> wrote:
>> I really feel like there is some point-missing going on here. It i= s trivial to make this feature only activate for clients that support it. I= f that is done, then there is no reason to assign an address at all. The of= fer doesn=E2=80=99t even need to include that option. So any discussion of = what address to send is irrelevant and unnecessary.
>
> The goal is that whatever the server does, it should be able to
> distinguish it=C2=A0 from any failure scenarios and stop asking. That&= #39;s the
> reason why we are not suggesting that
> the server should just ignore requests from the clients if the clients=
> sends the option. The positive signal 'I understand the option and=
> this network is offering IPv6-only service'. Is there any way to d= o it
> w/o sending an OFFER back?
>
>>
>>>> On Dec 6, 2019, at 06:10, Philip Homburg <pch-v6ops-9@u-1.phicoh.c= om> wrote:
>>>
>>> =EF=BB=BF
>>>>
>>>> "number of IPv4 addresses in the pool" comes to = mind.
>>>>
>>>> Like, 80% of all hosts are fine with IPv6+NAT64, so why pr= ovision a large
>>>> enough subnet to cover 100% of all expected hosts if 20% w= ill do?
>>>>
>>>> IPv4 seems to be somewhat in short supply these days.
>>>
>>> With a few exceptions, just about any DHCP pool I come across = these
>>> days is using RFC 1918.
>>>
>>> Are you running out of RFC 1918 addresses in your pool? Or is = the setup
>>> that you give publicly routable IPv4 addresses to all dual sta= ck hosts
>>> and want to only put hosts that support NAT64 behind NAT?
>>>
>>> In that case, what's the rational for providing dual stack= hosts with public
>>> IPv4 addresses?
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/v6ops<= /a>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >
>
>
> --
> SY, Jen Linkova aka Furry

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000006394fd05993faa53-- From nobody Sun Dec 8 23:31:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7190212010C; Sun, 8 Dec 2019 23:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.744 X-Spam-Level: X-Spam-Status: No, score=0.744 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCaJA1jvLO9R; Sun, 8 Dec 2019 23:31:41 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B118120033; Sun, 8 Dec 2019 23:31:41 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id h20so11354007otn.5; Sun, 08 Dec 2019 23:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHRGVrbw+sbrY3QxbKVz6JsYAO2i2PDpSzzya5ue4xE=; b=aYdywBG4xc84j9YGZukRly+ArB8FVOb4s3BEdhCqyMdYBZuPpLFSDZJaK09HUtsrFu VGq2LjrfkvDLVfRJqTaFKG4Gno1L+5P3XxXmigAJ//s6bMo/n/6KVMBWatxuJsfzZplx bHZbwSysX/Hm62Qp808bafS5XZgj2TIrT4xN7PhuooO/exP0xKXfniPDiLvDMOIM70Hg 09VkEY4U27lp4VUgEotD/eLMaUPnrLbcU0hSypn8To6oOckoSyAuLrGL8AGw+pjjfsss 0g1wnq5t9pLAnad+LS5nV9lvrWU++L1Uen1+YYsfTLJ6Yo7KFwC16cdPfRI74d0MDKBr dX4A== 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=sHRGVrbw+sbrY3QxbKVz6JsYAO2i2PDpSzzya5ue4xE=; b=sidM+mqGzbVn74MfldVSsEhQw9MWHrWaiF3LNO8MArnShSIaywZqJz3zL3nSmXAa6U 2YddFBsGnWLhJRuBDqMMlIH7PkAYoN62f1Y2MZg99fPdpxhui+ZfmVnDR8a2l5D7cpIq 2U9j5g8RklN/DUE6DgP+Z5ANHd3EgTP2Y3v6PbL/lSmuW7bHe3ecdMvurLqbndX2mEpM tdPNl5JXRngEdpJTKFPHlX1DdQD/9DEAsakhOmT8R5OkdzGvqBKd4xBK9pPjTLcLUiO2 78JV+7xC/awVyqTf8KuToZQz/LdULqDZpDB0rnJ8slLy78P/ibF6COLtsbjnc7VTqw6L exow== X-Gm-Message-State: APjAAAX997zRAFp1Lacp4RGC432UWNJJd0TEPdR2dz4sQacNX3d35HC0 VtUypUtLs3onnVRNtFnWEiSBulWDfl/wuvh3RLo= X-Google-Smtp-Source: APXvYqx9/li0y+xAL22QLRAYPzcsxPQ08pNZC49ig1384mSBuyRaX6hP/bGXAuYV59nFtdLQa/+Y6cj0B+X31q3pgB0= X-Received: by 2002:a9d:6005:: with SMTP id h5mr21670524otj.153.1575876700428; Sun, 08 Dec 2019 23:31:40 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> In-Reply-To: From: Mark Smith Date: Mon, 9 Dec 2019 18:31:29 +1100 Message-ID: To: Lorenzo Colitti Cc: Jen Linkova , v6ops list , "draft-link-dhc-v6only@ietf.org" , Michael Richardson , "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f05df105994062fe" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 07:31:43 -0000 --000000000000f05df105994062fe Content-Type: text/plain; charset="UTF-8" On Mon, 9 Dec 2019, 17:03 Lorenzo Colitti, wrote: > On Mon, Dec 9, 2019 at 9:54 AM Jen Linkova wrote: > >> I'm fine with it. I'll remove the reference to a dedicated address to >> return. >> So just to summarise the discussion: we have a number of options on the >> table: >> a) let server just return *an* address from the pool, assuming that as >> the host would not accept the offer anyway, the address will be made >> available again soon; >> pros: >> --- no changes on the server side; >> --- it would look normal to smart middle boxes >> cons: >> --- might lead to higher pool utilisation >> b) return some bogus address (0.0.0.0 or smth else) >> pros: >> --- client would not be able to assign it (hmm..theoretically) >> --- optimized pool usage >> cons: >> --- requires changes on the server >> --- might trigger unexpected behaviour on smart middle boxes >> (==> slowing down the adoption) >> >> c) do not offer anything, do smth esle instead (what exactly?) >> >> After writing it down like that I do agree that we shall probably choose >> a) ;) >> > > I would change b) "return 0.0.0.0" and add: > A possible idea related to this: - issue a unique IPv4 link local addresses i.e. from within 169.254.0.0/16 - specify a subnet mask for the address of 255.255.255.255 - don't provide a default router It is legitimate to reuse 169.254.0.0/16 on many different links. A subnet mask of 255.255.255.255 says to the host that all destinations are reachable via the default router, and that there are no reachable destinations directly on the link. However, as there is no default router to forward to, the host itself would generate a destination unreachable message and give it to the sending application. (A multi-homed host is likely to have a default route out one of its other interfaces. Source address selection should choose that other interface's IPv4 address rather than the 169.254.0.0/16 address. The 169.254.0.0/16 interface wouldn't be used.) Regards, Mark. > d) configure a specific address from the pool for all IPv6-only-capable > clients > pros: > --- most efficiently preserves IPv4 addresses. Always works even if > all clients ask for an address at the same time. > cons: > --- requires changes on the server > --- client cannot actually get the address, so if it sends a > request, things won't go well. > > In that sense I think b) is a non-starter, and I don't think c) is > feasible either: we do need to return something to the client, otherwise it > can't know that IPv6-only will work, and I don't think there's anything > other than OFFER that the server respond with (I don't think NAK is > typically sent in response to DISCOVER). > > So I think we're down to a) offer a regular address from the pool, and d) > offer a bogus address. The draft attempts to do both right now. I wonder if > we could leave d) in the text, but make it clear that it's just a possible > optimization? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000f05df105994062fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 9 Dec 2019, 17:03 Lorenzo Colitti, <lorenzo= =3D40google.com@dmarc.ietf.o= rg> wrote:
On Mon, Dec 9, 2019 at 9:54 AM Jen Linko= va <furry13@gmail.com> wrote:
I'm fine w= ith it. I'll remove the reference to a dedicated address to return.
So just to summarise the discussion: we have a number of options on the tab= le:
a) let server just return *an* address from the pool, assuming that as
the host would not accept the offer anyway, the address will be made
available again soon;
=C2=A0 =C2=A0pros:
=C2=A0 =C2=A0 =C2=A0 --- no changes on the server side;
=C2=A0 =C2=A0 =C2=A0 --- it would look normal to smart middle boxes
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- might lead to higher pool utilisation
b) return some bogus address (0.0.0.0 or smth else)
=C2=A0 =C2=A0 pros:
=C2=A0 =C2=A0 =C2=A0 =C2=A0--- client would not be able to assign it (hmm..= theoretically)
=C2=A0 =C2=A0 =C2=A0 --- optimized pool usage
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- requires changes on the server
=C2=A0 =C2=A0 =C2=A0 --- might trigger unexpected behaviour on smart middle= boxes
(=3D=3D> slowing down the adoption)

c) do not offer anything, do smth esle instead (what exactly?)

After writing it down like that I do agree that we shall probably choose a)= ;)

I would change b) "return 0.0.= 0.0" and add:


A possible idea related to this:

- issue a unique IPv4 link local addresses = i.e. from within=C2=A0169.254.0.0/16

- specify a subnet mask for the address of 255.255.255.255

- don't provide a default router
It= is legitimate to reuse=C2=A0169.254.0.0/16=C2=A0on many different links.

A subnet mask of 255.255.255.255 says to the host that all destin= ations are reachable via the default router, and that there are no reachabl= e destinations directly on the link.=C2=A0

However, as there is no default router to forward to, the host = itself would generate a destination unreachable message and give it to the = sending application.

(A multi= -homed host is likely to have a default route out one of its other interfac= es. Source address selection should choose that other interface's IPv4 = address rather than the=C2=A0169.254.0.0/16=C2=A0address. The 169.254.0.0/= 16 interface wouldn't be used.)


Regards,
Mark.
<= br>






d) configure a specific = address from the pool for all IPv6-only-capable clients
=C2=A0 = =C2=A0 pros:
=C2=A0 =C2=A0 =C2=A0 =C2=A0--- most efficiently preserves IPv4 addresses. A= lways works even if all clients ask for an address at the same time.
=C2=A0 =C2=A0cons:
=C2=A0 =C2=A0 =C2=A0 --- requires changes on the server
=C2= =A0 =C2=A0 =C2=A0 --- client cannot actually get the address, so if it send= s a request, things won't go well.

In that= sense I think b) is a non-starter, and I don't think c) is feasible ei= ther: we do need to return something to the client, otherwise it can't = know that IPv6-only will work, and I don't think there's anything o= ther than OFFER that the server respond with (I don't think NAK is typi= cally sent in response to DISCOVER).

So I think we= 're down to a) offer a regular address from the pool, and d) offer a bo= gus address. The draft attempts to do both right now. I wonder if we could = leave d) in the text, but make it clear that it's just a possible optim= ization?
_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000f05df105994062fe-- From nobody Mon Dec 9 05:50:59 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71F1201EA for ; Mon, 9 Dec 2019 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 096rKM3q0Pxd for ; Mon, 9 Dec 2019 05:50:55 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242FE1200C4 for ; Mon, 9 Dec 2019 05:50:55 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id b9so6755283pgk.12 for ; Mon, 09 Dec 2019 05:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=fldyxeD5Q1iHjGv3Mf7II91ofVjfDE/nHo+gh0j4AII=; b=Pm1Eebp37cE7bQklsllKf2yPQADeOYZDz759inczzV+8wj+DKzHLUOFjYlMovWYPL9 Ewog2iZ4nPuaqx/NZWgsFrgXiIoqyeHLwfuoWT+Ftbmw1iEvEpS18RIy4BnV/w0l04Qo Gn8zk4FWeWIuIgo5LpX4x/77PBbMd6ojywGkQpnnl56PajPS2+qDetoy+sqEXK+vrwWt 1o5w3jfi/QBdMrqWfCYTMvbrELFaer6QFlpOjHLODAARVNshONeLGv1PFqLA5HTrdemr YYD9D/xlq9YGvRuYZhCLIJgbwqJNRNystuG1D7eKHcLFQl35bDOugIJETx6g8wC0LAhE wDlQ== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=fldyxeD5Q1iHjGv3Mf7II91ofVjfDE/nHo+gh0j4AII=; b=FG+3Qps8isVLAt88r/vm3h+8rcpSDrlOd6xtEIygfJgJYoh6J5TpXoDYVbpuft0eWC ZVv07yNorh89h1HRMu+dRo/KRswKalUp/c4AuJnRWdI7Dse1ixfZsKY/QbGQ20lh80Uh hzvRVSrnDiXUQS1VmGwGg3DcH/P+zULrTii3MFigc2vLnWengGR/NRE0pkJdJVRKby1d lSf+hfyRmnCuvo6i6NvRE5TqktizzIjSx+uFKMNFSfph2oR1GB0Yo2oZCN4CeB406per BGEhFvQZ99MZgMODs0+5a57go8NBlRmvDXiEaRH1GzJCgXNeXjaEt1HARsURrcFexlTA VL2Q== X-Gm-Message-State: APjAAAWpV8nsI3itt8Zg0QNT0rDGrP9Ur3PoMHYflSV4lIXhOvru6wEX ylUK1L1KhTEmT7HEX0vAcjdQ7A== X-Google-Smtp-Source: APXvYqx8PZyyrCLZmDXqDJQUl1jhF5zhD5g/9FU+xIZSENsXv1JsFdgZD+YejOk2PpJhpvL50c0Wzw== X-Received: by 2002:a65:4344:: with SMTP id k4mr18450709pgq.193.1575899454619; Mon, 09 Dec 2019 05:50:54 -0800 (PST) Received: from ?IPv6:2600:380:856c:cbd0:f4d8:4261:16a2:288f? ([2600:380:856c:cbd0:f4d8:4261:16a2:288f]) by smtp.gmail.com with ESMTPSA id j18sm25153262pgk.1.2019.12.09.05.50.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 05:50:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 9 Dec 2019 05:50:52 -0800 Message-Id: <40C5B176-F2F4-491F-B6F6-6410A93A04F9@fugue.com> References: Cc: Jen Linkova , V6 Ops List , "draft-link-dhc-v6only@ietf.org" , Michael Richardson , "dhcwg@ietf.org" In-Reply-To: To: Lorenzo Colitti X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 13:50:57 -0000 If we return the option, that should be enough.=20 > On Dec 8, 2019, at 22:03, Lorenzo Colitti wrote: >=20 > In that sense I think b) is a non-starter, and I don't think c) is feasibl= e either: we do need to return something to the client, otherwise it can't k= now that IPv6-only will work, and I don't think there's anything other than O= FFER that the server respond with (I don't think NAK is typically sent in re= sponse to DISCOVER). From nobody Mon Dec 9 05:56:00 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3761200C4 for ; Mon, 9 Dec 2019 05:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xQr3vGKFzb5f for ; Mon, 9 Dec 2019 05:55:56 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042EC120024 for ; Mon, 9 Dec 2019 05:55:56 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id x7so7150733pgl.11 for ; Mon, 09 Dec 2019 05:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=3J1tEs5oHem0+TuHud2w7oGvhWALdfQmHXn3CdNBP0I=; b=AUljysnX+nadNdYpTCxVlEcrUrcC9MEMJQwL9Fr7lzDmGBbgqDKIZ1OIEI78HMEGuP a0u/TrYYmlQ/wuz1C2Nkq7ypHw4TS1t6RT0XrlfKun1AF2XT284F+G28tA0dhD+NYPPU bgNGrwTe8m8b/tWZeEUzGqCHjcel8+yg5gpetE5Tbfft1hRH2vsOGFtIOYou5F1o4nAi Il7vqR9UTUcgvkji3WNROMhgrf9Ef8I9YlOCVcp2RxMqeq28z7qsOxbeBHmVV9LrJRkj TxRnV4mA/VAZ+yG837ed84aLNIqr+cXs4umwYBW/zHMbvTbXcMeP6SsyEJCvsPt7lEKv QphQ== 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:cc:to; bh=3J1tEs5oHem0+TuHud2w7oGvhWALdfQmHXn3CdNBP0I=; b=gcly4ynGnguZSX4BoUj6ml0RbtlLrvt0TM2XMjggH94jcc1u1l2yQAssm9Xw0TZe0g qYIN9xZ45PyQQfJ0ygFVUNegd1ccHiyb1Ur/8LHI6J2fcF72ONHr6eLMBT0bQ5WQUqLU zA+H36do1SMMKLfkFNw2yzIG9Fd2Za/AydD4jai5NqJrBLL+uk+n+jNeR2M1grW2M6/g oi5aMOG6sXpf2VlHspNPA1zPjxv+NPY8e5oTqU4EWyTuqoizq9XWms9fcz3qQOteFpP8 9zmJ8iL4QHvRuPDzQc5w7LFtE2Vn/JMe88jtrVjMniz6Z3OKQfcY68SFEksYr3qYBNOw IgEQ== X-Gm-Message-State: APjAAAX2FcvSQTDGJX8JDNzsmMSuK4o9YyDphImNDJynHX3hvBmOuMX0 6ZC+/XPF61RyAfePX5wN22WGXw== X-Google-Smtp-Source: APXvYqw16CjY+dT4vvPGXbvuIaJV4hZSkk9abO+C9/7PTpU9GElbtwQ1XrFJasArr84zA0yHkyvhwg== X-Received: by 2002:a63:289:: with SMTP id 131mr18937504pgc.149.1575899755372; Mon, 09 Dec 2019 05:55:55 -0800 (PST) Received: from ?IPv6:2600:380:856c:cbd0:5159:5669:afa0:d14d? ([2600:380:856c:cbd0:5159:5669:afa0:d14d]) by smtp.gmail.com with ESMTPSA id s18sm27853043pfs.20.2019.12.09.05.55.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 05:55:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 9 Dec 2019 05:55:52 -0800 Message-Id: <910D2CD7-B3CF-4FEF-A34F-EE376196DF39@fugue.com> Cc: Jen Linkova , V6 Ops List To: Lorenzo Colitti X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 13:55:58 -0000 You said it yourself. If there=E2=80=99s a thundering herd, we don=E2=80=99t= have to wait for them all to time out, because there=E2=80=99s no limit to h= ow many answers we can send prior to acknowledgment. We don=E2=80=99t need t= o write anything to disk to give an answer. Plus, if something is snooping the DHCP exchange it won=E2=80=99t be able to= take any inappropriate action because the signaling on which it would base t= hat action is not present.=20 > On Dec 8, 2019, at 22:40, Lorenzo Colitti wrote: >=20 >=20 > It sounds like you're arguing that the network should put 0.0.0.0 in the y= iaddr field when sending an offer, even if doing so requires more server cha= nges. What I don't understand though, is: why? What is the advantage of putt= ing 0.0.0.0 in the offer? What do those server changes buy us? From nobody Mon Dec 9 06:00:35 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498021200CE for ; Mon, 9 Dec 2019 06:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=CQQi6cSR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zvId66dM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRrK3SUcTb2K for ; Mon, 9 Dec 2019 06:00:31 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60610120024 for ; Mon, 9 Dec 2019 06:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2028; q=dns/txt; s=iport; t=1575900031; x=1577109631; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DzgigaaYQW/EoG8KlX2y3sV2SOWDIXPbOmx8Xg/PGSM=; b=CQQi6cSRfBYg+2LvyTAt/W9/sCfdEcDMrmInKHH7X+3pqMs3YAepuV1z xt/50fPnd0xorj6zgh/bQmMqffYc/z4aF6ko8+OQwRWfjcynY2ldXVcx5 wqdF7F/eVxygZPquQidpn8XSyZVH3DVjMyEUpqMa+pzLDdbtQXq5XUnxT g=; IronPort-PHdr: =?us-ascii?q?9a23=3AxSQoJxRtYvNTlLIpVggptt71YNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUANfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5NksAKh0olCc+BB1f8Kav0aCgoNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQChUu5d/51dJa1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgW0EAQELAYFKUAVsWCAECyqEAoNGA4sCgjolmAWCUgNUCQEBAQw?= =?us-ascii?q?BARgLCgIBAYRAAheCAiQ3Bg4CAw0BAQQBAQECAQUEbYU3DIVSAQEBAQIBAQE?= =?us-ascii?q?QEREMAQEsCwEECwIBCA4KAgImAgICJQsVEAIEDgUfA4MAAYJGAw4gAQIMoDs?= =?us-ascii?q?CgTiIYXWBMoJ+AQEFgTUBgRSCRhiCFwMGgQ4oAYwXGoIAgTgMFIJMPoJkAQG?= =?us-ascii?q?BPRAWgxAygiyQJ542CoIulWYbmjKodQIEAgQFAg4BAQWBaCM3gSFwFTsqAYJ?= =?us-ascii?q?BUBEUjGYMF4NQhRSFP3SBKIsoAQYfghsBAQ?= X-IronPort-AV: E=Sophos;i="5.69,294,1571702400"; d="scan'208";a="389257557" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 14:00:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xB9E0UFG027751 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 14:00:30 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 08:00:29 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 08:00:29 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 08:00:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q5KUWhwIVORbaFNVwdsrCXmYJ0DbFhHvePa9Lp+sRQBadvBTQUZe1t/jRTQyNN3Cpwhvut995HOGEd0/Ie9pIFn58sbIuLzTUfqlxdJOWvC+8/1tBARmxy7KQOk2J7AQQ5gutzJm/KFxqeFDq5h1qsHVl0Td8LBzISVGyZp4T7l3Au+4UWef0TCNJTmW1btTfdXvcy76ppSGEfIvymQl+p/Wn0cTSKay1DRyaBcKX4oGT65qZ8Glx7JUIxAJVzKno2iYl/JBGKg0TMYZywAIspj8Z9acbZKu99FCtfgciBbPduAfQRqYv0Y8p/Bs1ZGWx58RBqLgkHrlrXcRmaKFBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DzgigaaYQW/EoG8KlX2y3sV2SOWDIXPbOmx8Xg/PGSM=; b=jqXiaQaulYMB5GLayQcNBKU/yn1DI+CXMGctl52gn07GtVAlT8BP8iWfoVvZq5VbmlYrpjMfBm7KZ2qbw9w+oNK4KJVNyRtNfS1bA6nOR1jSiBIR6DV6uLmzp8H7U0W4KDiuJ8GbNkXYn/IdsFaYfsvtifdy4GudvvtXsb58WyOPpcqaWEmJZJXZpanYXQW4dwCn4TqvT6IzpW+xzii/ggBhcwyfeMzFbcYqMnvAAdNrL/VrfcigK1+Z5w8qrNYPeyQCrpi8/43X/5g27PUvvZTWfHw2jMWVnB5ijdPoP7jbX1ZIeJf9CCwYA0/cI9gYeONaH+Z/U7HSOtBU1Ljawg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DzgigaaYQW/EoG8KlX2y3sV2SOWDIXPbOmx8Xg/PGSM=; b=zvId66dMApXbGoSZCXTemPgreEQjrigdyY9bcsP5Nu06SWNGGJwt277u6wT3rhbbSfCFmAWC5nQ+Wdpx3+oYbTS2f/egCdXdG+W4fO5SBarqgsSN+U9Qj/x49JSOtpG/u5yzACUktI6YLG8Y8AJQTjQoby5ffi3CVt3c5hxajTk= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB2777.namprd11.prod.outlook.com (20.176.95.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.22; Mon, 9 Dec 2019 14:00:28 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 14:00:28 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Lorenzo Colitti , V6 Ops List Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrph2epYC8FtIKky3loNP84z23aex1NRp Date: Mon, 9 Dec 2019 14:00:28 +0000 Message-ID: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com> References: <910D2CD7-B3CF-4FEF-A34F-EE376196DF39@fugue.com> In-Reply-To: <910D2CD7-B3CF-4FEF-A34F-EE376196DF39@fugue.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=volz@cisco.com; x-originating-ip: [2600:1000:b040:e741:54d3:c47d:a977:83e9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4438cb6f-6abd-4e64-2855-08d77cb025bb x-ms-traffictypediagnostic: DM6PR11MB2777: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(346002)(396003)(199004)(189003)(66446008)(66556008)(6512007)(5660300002)(64756008)(305945005)(6486002)(36756003)(66476007)(4326008)(91956017)(229853002)(76116006)(66946007)(6916009)(186003)(316002)(81156014)(53546011)(6506007)(966005)(2906002)(478600001)(8676002)(81166006)(86362001)(71200400001)(8936002)(54906003)(2616005)(71190400001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2777; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pv+AcD11RHmAh6DmMymaE6sAJiQRD3Tt6Vi6VirQCZcOzsMvI+6OS0sJDqqwy1Zjc7CDccwKW8EowcimMMPUXGFVw+QEDzjuFS9iSWUDEvQNQGbithUC3X9JEb3NdFsa9SmYiQI9kbt+FSm4emtwIxiJuxEuuzkjeiY1ge3+XsZScE6TPgVWssOBsk77a8cEoGYkG+Wm2MP4m0QBd/L3esLCjF2jy26Pwr6ZoYmVr6tx4PNGUocjQzn7klTzlxq1scnRuPEeVA2F9mGd5oCdAepydSCaxAdVPDqlrNXmdcXF55MRyLduzBixpojqW/1TSbhtmEgZ5RdEnil6gbEj96LEIBN3J5J0La1mNigxOQ66Kh3sER1Tx4KU1tGInld1ByRJlt5nXjwCRgoQTIgZZbxVX7Na+Fekf52DyE9OfHif844K4gdrlhwwoo0ufY0jT6kJbCFwQJ28BWG+rQq1BrLLULiAQg9om1nmn+H7Y8E= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4438cb6f-6abd-4e64-2855-08d77cb025bb X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 14:00:28.3106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XaHOn2WUITe80jJwdneXx3MMEvNQ5wppsU22x48WajJGc4uRxUJJQAVQO0NUSlx0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2777 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 14:00:33 -0000 V2UgYWxyZWFkeSBkb27igJl0IGNvbW1pdCB0byBkaXNrIHBlciByZmMyMTMxIGFuZCB1c2UgYSBz aG9ydCwgdHVuZWFibGUgdGltZS1vdXQuIFNvLCBhZ2Fpbiwgd2UgYXJlIGFsbCBzZXQgd2l0aG91 dCBzZXJ2ZXIgY2hhbmdlcy4NCg0KWW91IGNhbiBhbHNvIGNsYXNzaWZ5IHRoZXNlIGRldmljZXMg aW50byBhIHNlcGFyYXRlIGNsaWVudCBjbGFzcyB0byByZWR1Y2UgdGltZW91dCBmb3IgdGhlbSAo c3VjaCBhcyB0byBhIGZldyBzZWNvbmRzKS4NCg0KQWdhaW4sIEkgc2VlIG5vIG5lZWQgZm9yIHNw ZWNpYWwgc2VydmVyIGNoYW5nZXMuDQoNCklmIGEgc2VydmVyIGRvZXNu4oCZdCBwcm92aWRlIGZv ciB0aGVzZSBtZWNoYW5pY3MsIHRoZSBzZXJ2ZXIgc2hvdWxkLiBCdXQgdGhpcyBpcyBjb25maWd1 cmF0aW9uIGlzc3VlLCBub3QgcHJvdG9jb2wgaXNzdWUuDQoNCi0gQmVybmllDQoNCj4gT24gRGVj IDksIDIwMTksIGF0IDg6NTYgQU0sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4gd3JvdGU6 DQo+IA0KPiDvu79Zb3Ugc2FpZCBpdCB5b3Vyc2VsZi4gSWYgdGhlcmXigJlzIGEgdGh1bmRlcmlu ZyBoZXJkLCB3ZSBkb27igJl0IGhhdmUgdG8gd2FpdCBmb3IgdGhlbSBhbGwgdG8gdGltZSBvdXQs IGJlY2F1c2UgdGhlcmXigJlzIG5vIGxpbWl0IHRvIGhvdyBtYW55IGFuc3dlcnMgd2UgIGNhbiBz ZW5kIHByaW9yIHRvIGFja25vd2xlZGdtZW50LiBXZSBkb27igJl0IG5lZWQgdG8gd3JpdGUgYW55 dGhpbmcgdG8gZGlzayB0byBnaXZlIGFuIGFuc3dlci4NCj4gDQo+IFBsdXMsIGlmIHNvbWV0aGlu ZyBpcyBzbm9vcGluZyB0aGUgREhDUCBleGNoYW5nZSBpdCB3b27igJl0IGJlIGFibGUgdG8gdGFr ZSBhbnkgaW5hcHByb3ByaWF0ZSBhY3Rpb24gYmVjYXVzZSB0aGUgc2lnbmFsaW5nIG9uIHdoaWNo IGl0IHdvdWxkIGJhc2UgdGhhdCBhY3Rpb24gaXMgbm90IHByZXNlbnQuIA0KPiANCj4+IE9uIERl YyA4LCAyMDE5LCBhdCAyMjo0MCwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+ IHdyb3RlOg0KPj4gDQo+PiANCj4+IEl0IHNvdW5kcyBsaWtlIHlvdSdyZSBhcmd1aW5nIHRoYXQg dGhlIG5ldHdvcmsgc2hvdWxkIHB1dCAwLjAuMC4wIGluIHRoZSB5aWFkZHIgZmllbGQgd2hlbiBz ZW5kaW5nIGFuIG9mZmVyLCBldmVuIGlmIGRvaW5nIHNvIHJlcXVpcmVzIG1vcmUgc2VydmVyIGNo YW5nZXMuIFdoYXQgSSBkb24ndCB1bmRlcnN0YW5kIHRob3VnaCwgaXM6IHdoeT8gV2hhdCBpcyB0 aGUgYWR2YW50YWdlIG9mIHB1dHRpbmcgMC4wLjAuMCBpbiB0aGUgb2ZmZXI/IFdoYXQgZG8gdGhv c2Ugc2VydmVyIGNoYW5nZXMgYnV5IHVzPw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Dec 9 06:17:16 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C55120089 for ; Mon, 9 Dec 2019 06:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nG4axTDmTXW2 for ; Mon, 9 Dec 2019 06:17:13 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6F0120024 for ; Mon, 9 Dec 2019 06:17:13 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id d199so7306628pfd.11 for ; Mon, 09 Dec 2019 06:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gJOzT9ytpKmDOtDqors3u3MC6iSH2x1oa2u7lRxYjEI=; b=ZDCUr7Ax66TlaOyAsTjgylecLYGc5W/7f8zfNHKpDm8Lzf0y11N+pIFAfzh7Un+wTZ 12pXh07D9acpnNY4PaOZtKty700JoGvKtiosANPEi88hj3NagdYnnVKHEKlwcicFRhQa 7qtb25auolaYlBKh7ECer2MWEJ22pBUzYBbJiRTrUW9TVGAEupHZAX6Y/rRCQHgi1b73 feP5VpWOJ8gDndKOZbGWs2375FtQyld+HgLC8AQ+I/MuqNEzV36p+8wCLJRJxXlduC0f hG3RyPa9EiJgpQkscQeIyuFbDGGoCRgBGk9BAE8k8seIVPAAVButFDjAwgRm0XB/cgOS Batg== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=gJOzT9ytpKmDOtDqors3u3MC6iSH2x1oa2u7lRxYjEI=; b=V81tPmxKU6ThcUqa02cr6Fh+Tm+XT7DvDJfmpd9nLs8WyTBWmqjZb9mc4aHF6dCgiO nIUD6Sfsuet+HQWLoS93Xy5y/r7+L8OPpGC2iRUpjadJdycB2+7Uz8Pwh5PmT5qQFO0Y ebBPTi2yAng+dnH5hlTZCJgYRNdCVngksI/k+lJigAAO/E07HK/2iUf0Q8g7h8hqpGQG 3uu7VX7MaCuUBPSCbiZdvCU2cuatnm87xvyspbJrXaLSknPVXfkK52/4wCwL9pgAH1lz 5ehXKMbz4p2fjjKETBU8LXPnaADB1d4PvaZtwgmqOa3PVy6Dnvz+CuM8jw1tKbwncgny gzjw== X-Gm-Message-State: APjAAAU1dwObGh1Mo3ZRzDRHGgtFLkI4iT/mHjUxMo1TBf+7SVx9iJM5 qRWhm9t4iefLVpaCC+j3gLYpkQ== X-Google-Smtp-Source: APXvYqyb7o8oj16m0VANMRopT0V080XZTeRZTlmVKTdg4RKYVCJlJzzuGmAdF3VmH1BYIhOanMS2Yg== X-Received: by 2002:a65:56c9:: with SMTP id w9mr18328769pgs.296.1575901033105; Mon, 09 Dec 2019 06:17:13 -0800 (PST) Received: from ?IPv6:2600:380:856c:cbd0:5159:5669:afa0:d14d? ([2600:380:856c:cbd0:5159:5669:afa0:d14d]) by smtp.gmail.com with ESMTPSA id d38sm24646462pgd.59.2019.12.09.06.17.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 06:17:12 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-20B59A63-85F1-4966-B4AC-78CFBAA59C60 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 9 Dec 2019 06:17:10 -0800 Message-Id: References: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com> Cc: Lorenzo Colitti , V6 Ops List In-Reply-To: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com> To: "Bernie Volz (volz)" X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 14:17:15 -0000 --Apple-Mail-20B59A63-85F1-4966-B4AC-78CFBAA59C60 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Dec 9, 2019, at 06:00, Bernie Volz (volz) wrote: >=20 > =EF=BB=BFWe already don=E2=80=99t commit to disk per rfc2131 and use a sho= rt, tuneable time-out. So, again, we are all set without server changes.=20 Does rfc2131 actually say that? > You can also classify these devices into a separate client class to reduce= timeout for them (such as to a few seconds). >=20 That=E2=80=99s a special server change.=20 > Again, I see no need for special server changes. >=20 > If a server doesn=E2=80=99t provide for these mechanics, the server should= . But this is configuration issue, not protocol issue. So servers other than yours should be the ones that have to change? :) The reason I think this merits a change is that we actually want different b= ehavior. The change is trivial. You aren=E2=80=99t actually arguing for no change: you are arguing for a cha= nge that is minimally inconvenient assuming a certain existing implementatio= n. That is a good short term move, but this is a long term solution. So I=E2=80= =99m arguing to do it right.=20 One way to resolve this impasse would be to specify it do it would work with= your minimal change, but also allow the server to send no address in the of= fer. That way you can implement the full change at your leisure, but we stil= l get a good long term outcome.=20 --Apple-Mail-20B59A63-85F1-4966-B4AC-78CFBAA59C60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Dec 9, 2019, at 06:00, B= ernie Volz (volz) <volz@cisco.com> wrote:

=EF=BB=BFWe already don=E2=80=99t commit to disk per rfc2131= and use a short, tuneable time-out. So, again, we are all set without serve= r changes. 

Does rfc21= 31 actually say that?

You can also classify these devices into a separate client cl= ass to reduce timeout for them (such as to a few seconds).
<= /span>

That=E2=80=99s a special server change. = ;

Again= , I see no need for special server changes.

If a server doesn=E2=80=99t provide for these mechanics, the server should.= But this is configuration issue, not protocol issue.

So servers other than yours should be the ones that ha= ve to change?  :)

The reason I think this meri= ts a change is that we actually want different behavior. The change i= s trivial.

You aren=E2=80=99t actually arguing for n= o change: you are arguing for a change that is minimally inconvenient assumi= ng a certain existing implementation.

That is a goo= d short term move, but this is a long term solution. So I=E2=80=99m arguing t= o do it right. 

One way to resolve this impass= e would be to specify it do it would work with your minimal change, b= ut also allow the server to send no address in the offer. That way yo= u can implement the full change at your leisure, but we still get a good lon= g term outcome. 

= --Apple-Mail-20B59A63-85F1-4966-B4AC-78CFBAA59C60-- From nobody Mon Dec 9 06:32:08 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40CB12004E for ; Mon, 9 Dec 2019 06:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YqPOYB6H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KRSJ/WcZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlUC4pn1ERoR for ; Mon, 9 Dec 2019 06:32:04 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B2912000F for ; Mon, 9 Dec 2019 06:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8277; q=dns/txt; s=iport; t=1575901924; x=1577111524; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t4e9jjlSomjr2SblOIXKFiTFIE+az7ETvk0Clcm1Ohs=; b=YqPOYB6H5XSyexlh5PIwznioYtvcjxywJ0Ij7aLIhCOsjZJI4bISEPDO vkBqeURBsKd0ahRwqEbuetCz+g8B8YrJ84Bh+jM0UrnWmeRsNIZ87HwFb OmG2uOzDsuESdsMTA8ZkXP7aLxtR3nP8XI3SYscWvDA4Zc7UAIrqO1at7 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AOEWSJxX9HM/NHuREhL984NEHDs7V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/cSs+DuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgAbWu5d/5ldJa1kHQEBAQkBEQU?= =?us-ascii?q?FAYFtBQELAYFKUAWBRCAECyqEAoNGA4sCgjqTSIRiglIDVAkBAQEMAQEtAgE?= =?us-ascii?q?BhEACF4ICJDcGDgIDDQEBBAEBAQIBBQRthTcMhVMCAQMSER0BATcBDwIBCA4?= =?us-ascii?q?0AgICMCUCBA4FGweDAIF6TQMuAQKhBwKBOIhhdYEygn4BAQWCSoJJGIIXCYE?= =?us-ascii?q?2AYwXGoIAgTgMFIJMPoQzgyYygiyQJ4VQmGYKgi6VZhuaMqh1AgQCBAUCDgE?= =?us-ascii?q?BBYFoI4FYcBVlAYJBUBEUjGaDc4pTdIEojWkBAQ?= X-IronPort-AV: E=Sophos;i="5.69,296,1571702400"; d="scan'208,217";a="379342908" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 14:32:02 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xB9EW2uL022916 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 14:32:02 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 08:32:02 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:32:00 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 08:32:00 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WzKJmJ86Bk3JUtFlwEIZ0J24ucQnLaUkMnZO36ZjW0/nnMh69HF8jsykMaCbCpFdMA1EcBTEZsv8WQl1Ftw7JwLxJV4kSIZ9+Jn5RWz4+9e405zXf/AMdQCtvFiIZEz3U1tkuDOwizImjlbuVxb2Ba5UOjkaOp94flIxtbvSBmohhB38gL3lObPtVLtf4yqJCIJ3GIvrsk6etQgn4KkL8MSukgLs0rPP3WpoPtBdHbjoutOF7fO52M4OetSAK2yxvbjyePyyG6iEw4qNRPUjd2BEtIJwaUXgt2Ck/fLgmnmlY8kKnZVReCVX0+MeUJk759jkyt9+cZNKeyC091EM1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t4e9jjlSomjr2SblOIXKFiTFIE+az7ETvk0Clcm1Ohs=; b=jJAXOdoITkrpnrToFDhV8kZeALaxEkP7cpQjXo7YAqCVr8XGh+u6Y2BR+budNwFj0mIYG3YHIlhbVURP7MZuesDEK98/5FMZFLWk0LfrWaTautpBCrRKIlBMRceqyomiZcSJip6r+8/CWYgumJIwGEf53OeuGMBqAQrPkT6i1UrVoz/TEovPOJP42CVZEWthF/aS3Ofr99F2Vvzmgzpcy46ByslhvVfYeKNAh/SSv5Mop3C8s4hx/SnWtrzPNZJ9X4Z7E2lXAKMrVrD+KpzjIzot1nmyKCU5dVhtvhioF4XFcDeocKIaLnv0V0eSr2m9z8KshqtcPWOi6rU9XLM6Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t4e9jjlSomjr2SblOIXKFiTFIE+az7ETvk0Clcm1Ohs=; b=KRSJ/WcZkz9aZQzRVbyImfAbJWpOPheClqf1Y2jO9DNANzkjxieoBRZSFzAsXB2EhQ/v/ey/TjgYKa8Omfs3g4QEPxSis6kqthAvF4qk0p+ohNIpZeISAAdrsKwNLne/R2c2vifN772C9Hs3gwPNMeyrixKoZDgvZEEpGNTQSP8= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3946.namprd11.prod.outlook.com (20.176.127.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Mon, 9 Dec 2019 14:31:58 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 14:31:58 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Lorenzo Colitti , V6 Ops List Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrph2epYC8FtIKky3loNP84z23aex1NRpgAAEqwCAAAQjEA== Date: Mon, 9 Dec 2019 14:31:58 +0000 Message-ID: References: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [2600:1000:b040:e741:54d3:c47d:a977:83e9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ac5621c-abdf-415a-8c22-08d77cb48c56 x-ms-traffictypediagnostic: DM6PR11MB3946: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(346002)(136003)(199004)(189003)(86362001)(33656002)(91956017)(54906003)(186003)(478600001)(2616005)(6506007)(53546011)(5660300002)(8936002)(71190400001)(76116006)(81156014)(71200400001)(4326008)(8676002)(81166006)(229853002)(6512007)(2906002)(66446008)(66946007)(6916009)(36756003)(6486002)(64756008)(66476007)(66556008)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3946; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IHifWQqIKXzSil4RnDy7qiw7awtiQ/M6mwMB7NJwKXwFsbomt6/jmzeuyGflBDSx1hbDXomN7PCBekMSSrqszmt0PY3JDUdqax0Uwfj78b3tgy5Kw3Shk7bucOIeDQioYVdv0zoQUiDsjNdAZtUiJYU4oIh4jCnUyzdpL/rTXlsflicJKrlYy6/1k0Tew7gc14Erjyl3Jf9sN47PHPO2ZXufi49z4EDysZGE3s7U8mJbUcKjzxNcKxMV62zA1uyRUQToOcWKm4Gw3krzn/i9K83eonkUKJ67x1LwIUcaLy1tlnDgvOtuDhp2PflMhSA2463aYdfOnHrLR7NrMdVfQO5zlxbDhrGS6r0O+pU8Ik81EvtWW08FnXNVI5oTE1x0HCPnD/RK+2PBph9lTr/eT2SqHZOZLOZ339uQ0F6L2+dnO1lLgYsExdwgwdp4V2Ch x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F5AAD5B722BD44749A1E1A97AFFE47FCciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ac5621c-abdf-415a-8c22-08d77cb48c56 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 14:31:58.5604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d8zUu7RVB3mKeWmcrgFmuCqvtp6ttQBn4YvViJATQFActkFvlfYmqGG8w4F0i0+Z X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3946 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 14:32:07 -0000 --_000_F5AAD5B722BD44749A1E1A97AFFE47FCciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEkgYW0gc3Ryb25nbHkgYXJndWluZyBmb3Igbm8gY2hhbmdlLg0KDQpBZ2FpbiwgdGhlIHRo aW5ncyBJIHN1Z2dlc3RlZCBhcmUgb3B0aW1pemF0aW9ucyBpZiB5b3UgZmVlbCB0aGVyZSBpcyBh IG5lZWQgdG8gcmVkdWNlIHRoZSBpbXBhY3QgaWYgbG90cyBvZiBjbGllbnRzIGNvbWUgb25saW5l IGF0IHNhbWUgdGltZS4gWW91IGRvbuKAmXQgaGF2ZSB0byBkbyBhbnkgb2YgdGhlc2UgdGhpbmdz Lg0KDQpJZiBhIHNlcnZlciBjb21taXRzIGxlYXNlIHRvIGRpc2sgd2l0aCBmdWxsIGxlYXNlIHRp bWUgb24gYW4gb2ZmZXIsIHllcyB5b3UgaGF2ZSB0byBjaGFuZ2UgdGhhdC4gUmZjIDIxMzEgYWxy ZWFkeSBzdGF0ZXMgdGhhdCB0aGlzIGlzIGFwcHJvcHJpYXRlIHRvIGRvIChub3QgY29tbWl0LCB1 c2Ugc2hvcnQgdGltZSB0byBob2xkIGxlYXNlKS4NCg0KU3VyZSwgd2UgY2FuIGRvY3VtZW50IHRo YXQgYXMgc29tZXRoaW5nIHRoYXQgaXMgYSBjb25zaWRlcmF0aW9uIGlmIHlvdSBoYXZlIGxvdHMg b2YgY2xpZW50cyBhbmQgbm90IG11Y2ggYWRkcmVzcyBzcGFjZS4NCg0KU2VuZGluZyAwIGFkZHJl c3MgaXMgYmFkOg0KLSBtaWdodCBpbXBhY3QgbWlkZGxlYm94ZXMNCi0gaGFzIGlzc3VlcyBpZiBv cHRpb24gaGFzIGJlZW4gaGlqYWNrZWQgZm9yIG90aGVyIHB1cnBvc2VzIGFuZCBpcyBpbiBwcmwN Ci0gZG9lc27igJl0IGFsbG93IGNsaWVudCB0byBjb250aW51ZSB3aXRoIGxlYXNlIGlmIGl0IGNo YW5nZXMgaXRzIGNvbmZpZ3VyYXRpb24gYmV0d2VlbiBkaXNjb3ZlciAmIG9mZmVyDQoNCkFuZCBl dmVuIGlmIGFkZHJlc3NlcyBhbGwgdXNlZCwgcmV0cmFuc21pc3Npb25zIHdpbGwgYWxsb3cgY2xp ZW50IHRvIGV2ZW50dWFsbHkgcHJvY2VlZC4NCg0KLSBCZXJuaWUNCg0KT24gRGVjIDksIDIwMTks IGF0IDk6MTggQU0sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4gd3JvdGU6DQoNCu+7vw0K T24gRGVjIDksIDIwMTksIGF0IDA2OjAwLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28u Y29tPiB3cm90ZToNCg0K77u/V2UgYWxyZWFkeSBkb27igJl0IGNvbW1pdCB0byBkaXNrIHBlciBy ZmMyMTMxIGFuZCB1c2UgYSBzaG9ydCwgdHVuZWFibGUgdGltZS1vdXQuIFNvLCBhZ2Fpbiwgd2Ug YXJlIGFsbCBzZXQgd2l0aG91dCBzZXJ2ZXIgY2hhbmdlcy4NCg0KRG9lcyByZmMyMTMxIGFjdHVh bGx5IHNheSB0aGF0Pw0KDQpZb3UgY2FuIGFsc28gY2xhc3NpZnkgdGhlc2UgZGV2aWNlcyBpbnRv IGEgc2VwYXJhdGUgY2xpZW50IGNsYXNzIHRvIHJlZHVjZSB0aW1lb3V0IGZvciB0aGVtIChzdWNo IGFzIHRvIGEgZmV3IHNlY29uZHMpLg0KDQoNClRoYXTigJlzIGEgc3BlY2lhbCBzZXJ2ZXIgY2hh bmdlLg0KDQpBZ2FpbiwgSSBzZWUgbm8gbmVlZCBmb3Igc3BlY2lhbCBzZXJ2ZXIgY2hhbmdlcy4N Cg0KSWYgYSBzZXJ2ZXIgZG9lc27igJl0IHByb3ZpZGUgZm9yIHRoZXNlIG1lY2hhbmljcywgdGhl IHNlcnZlciBzaG91bGQuIEJ1dCB0aGlzIGlzIGNvbmZpZ3VyYXRpb24gaXNzdWUsIG5vdCBwcm90 b2NvbCBpc3N1ZS4NCg0KU28gc2VydmVycyBvdGhlciB0aGFuIHlvdXJzIHNob3VsZCBiZSB0aGUg b25lcyB0aGF0IGhhdmUgdG8gY2hhbmdlPyAgOikNCg0KVGhlIHJlYXNvbiBJIHRoaW5rIHRoaXMg bWVyaXRzIGEgY2hhbmdlIGlzIHRoYXQgd2UgYWN0dWFsbHkgd2FudCBkaWZmZXJlbnQgYmVoYXZp b3IuIFRoZSBjaGFuZ2UgaXMgdHJpdmlhbC4NCg0KWW91IGFyZW7igJl0IGFjdHVhbGx5IGFyZ3Vp bmcgZm9yIG5vIGNoYW5nZTogeW91IGFyZSBhcmd1aW5nIGZvciBhIGNoYW5nZSB0aGF0IGlzIG1p bmltYWxseSBpbmNvbnZlbmllbnQgYXNzdW1pbmcgYSBjZXJ0YWluIGV4aXN0aW5nIGltcGxlbWVu dGF0aW9uLg0KDQpUaGF0IGlzIGEgZ29vZCBzaG9ydCB0ZXJtIG1vdmUsIGJ1dCB0aGlzIGlzIGEg bG9uZyB0ZXJtIHNvbHV0aW9uLiBTbyBJ4oCZbSBhcmd1aW5nIHRvIGRvIGl0IHJpZ2h0Lg0KDQpP bmUgd2F5IHRvIHJlc29sdmUgdGhpcyBpbXBhc3NlIHdvdWxkIGJlIHRvIHNwZWNpZnkgaXQgZG8g aXQgd291bGQgd29yayB3aXRoIHlvdXIgbWluaW1hbCBjaGFuZ2UsIGJ1dCBhbHNvIGFsbG93IHRo ZSBzZXJ2ZXIgdG8gc2VuZCBubyBhZGRyZXNzIGluIHRoZSBvZmZlci4gVGhhdCB3YXkgeW91IGNh biBpbXBsZW1lbnQgdGhlIGZ1bGwgY2hhbmdlIGF0IHlvdXIgbGVpc3VyZSwgYnV0IHdlIHN0aWxs IGdldCBhIGdvb2QgbG9uZyB0ZXJtIG91dGNvbWUuDQoNCg== --_000_F5AAD5B722BD44749A1E1A97AFFE47FCciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpO bywgSSBhbSBzdHJvbmdseSBhcmd1aW5nIGZvciBubyBjaGFuZ2UuDQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5BZ2FpbiwgdGhlIHRoaW5ncyBJIHN1Z2dlc3RlZCBhcmUgb3B0aW1pemF0aW9ucyBp ZiB5b3UgZmVlbCB0aGVyZSBpcyBhIG5lZWQgdG8gcmVkdWNlIHRoZSBpbXBhY3QgaWYgbG90cyBv ZiBjbGllbnRzIGNvbWUgb25saW5lIGF0IHNhbWUgdGltZS4gWW91IGRvbuKAmXQgaGF2ZSB0byBk byBhbnkgb2YgdGhlc2UgdGhpbmdzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYg YSBzZXJ2ZXIgY29tbWl0cyBsZWFzZSB0byBkaXNrIHdpdGggZnVsbCBsZWFzZSB0aW1lIG9uIGFu IG9mZmVyLCB5ZXMgeW91IGhhdmUgdG8gY2hhbmdlIHRoYXQuIFJmYyAyMTMxIGFscmVhZHkgc3Rh dGVzIHRoYXQgdGhpcyBpcyBhcHByb3ByaWF0ZSB0byBkbyAobm90IGNvbW1pdCwgdXNlIHNob3J0 IHRpbWUgdG8gaG9sZCBsZWFzZSkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TdXJl LCB3ZSBjYW4gZG9jdW1lbnQgdGhhdCBhcyBzb21ldGhpbmcgdGhhdCBpcyBhIGNvbnNpZGVyYXRp b24gaWYgeW91IGhhdmUgbG90cyBvZiBjbGllbnRzIGFuZCBub3QgbXVjaCBhZGRyZXNzIHNwYWNl LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VuZGluZyAwIGFkZHJlc3MgaXMgYmFk OjwvZGl2Pg0KPGRpdj4tIG1pZ2h0IGltcGFjdCBtaWRkbGVib3hlczwvZGl2Pg0KPGRpdj4tIGhh cyBpc3N1ZXMgaWYgb3B0aW9uIGhhcyBiZWVuIGhpamFja2VkIGZvciBvdGhlciBwdXJwb3NlcyBh bmQgaXMgaW4gcHJsPC9kaXY+DQo8ZGl2Pi0gZG9lc27igJl0IGFsbG93IGNsaWVudCB0byBjb250 aW51ZSB3aXRoIGxlYXNlIGlmIGl0IGNoYW5nZXMgaXRzIGNvbmZpZ3VyYXRpb24gYmV0d2VlbiBk aXNjb3ZlciAmYW1wOyBvZmZlcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5kIGV2 ZW4gaWYgYWRkcmVzc2VzIGFsbCB1c2VkLCByZXRyYW5zbWlzc2lvbnMgd2lsbCBhbGxvdyBjbGll bnQgdG8gZXZlbnR1YWxseSBwcm9jZWVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2IGRpcj0ibHRy Ij4tIEJlcm5pZTwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+T24gRGVjIDksIDIwMTksIGF0IDk6MTggQU0sIFRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1 Z3VlLmNvbSZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPGRpdiBkaXI9Imx0ciI+ T24gRGVjIDksIDIwMTksIGF0IDA2OjAwLCBCZXJuaWUgVm9seiAodm9seikgJmx0O3ZvbHpAY2lz Y28uY29tJmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vzxzcGFuPldlIGFscmVhZHkgZG9u4oCZdCBjb21taXQg dG8gZGlzayBwZXIgcmZjMjEzMSBhbmQgdXNlIGEgc2hvcnQsIHR1bmVhYmxlIHRpbWUtb3V0LiBT bywgYWdhaW4sIHdlIGFyZSBhbGwgc2V0IHdpdGhvdXQgc2VydmVyIGNoYW5nZXMuJm5ic3A7PC9z cGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ RG9lcyByZmMyMTMxIGFjdHVhbGx5IHNheSB0aGF0PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+WW91IGNhbiBh bHNvIGNsYXNzaWZ5IHRoZXNlIGRldmljZXMgaW50byBhIHNlcGFyYXRlIGNsaWVudCBjbGFzcyB0 byByZWR1Y2UgdGltZW91dCBmb3IgdGhlbSAoc3VjaCBhcyB0byBhIGZldyBzZWNvbmRzKS48L3Nw YW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xv cjogcmdiKDAsIDAsIDApOyI+VGhhdOKAmXMgYSBzcGVjaWFsIHNlcnZlciBjaGFuZ2UuJm5ic3A7 PC9zcGFuPg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Ij48YnI+DQo8L3NwYW4+PC9mb250Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj5BZ2FpbiwgSSBzZWUgbm8gbmVlZCBmb3Ig c3BlY2lhbCBzZXJ2ZXIgY2hhbmdlcy48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxz cGFuPklmIGEgc2VydmVyIGRvZXNu4oCZdCBwcm92aWRlIGZvciB0aGVzZSBtZWNoYW5pY3MsIHRo ZSBzZXJ2ZXIgc2hvdWxkLiBCdXQgdGhpcyBpcyBjb25maWd1cmF0aW9uIGlzc3VlLCBub3QgcHJv dG9jb2wgaXNzdWUuPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9k aXY+DQo8ZGl2PlNvIHNlcnZlcnMgb3RoZXIgdGhhbiB5b3VycyBzaG91bGQgYmUgdGhlIG9uZXMg dGhhdCBoYXZlIHRvIGNoYW5nZT8gJm5ic3A7Oik8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlRoZSByZWFzb24gSSB0aGluayB0aGlzIG1lcml0cyBhIGNoYW5nZSBpcyB0aGF0IHdlIGFj dHVhbGx5IDxpPndhbnQ8L2k+IGRpZmZlcmVudCBiZWhhdmlvci4gVGhlIGNoYW5nZSBpcyB0cml2 aWFsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IGFyZW7igJl0IGFjdHVhbGx5 IGFyZ3VpbmcgZm9yIG5vIGNoYW5nZTogeW91IGFyZSBhcmd1aW5nIGZvciBhIGNoYW5nZSB0aGF0 IGlzIG1pbmltYWxseSBpbmNvbnZlbmllbnQgYXNzdW1pbmcgYSBjZXJ0YWluIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhdCBpcyBhIGdv b2Qgc2hvcnQgdGVybSBtb3ZlLCBidXQgdGhpcyBpcyBhIGxvbmcgdGVybSBzb2x1dGlvbi4gU28g SeKAmW0gYXJndWluZyB0byBkbyBpdCByaWdodC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pk9uZSB3YXkgdG8gcmVzb2x2ZSB0aGlzIGltcGFzc2Ugd291bGQgYmUgdG8gc3Bl Y2lmeSBpdCBkbyBpdCB3b3VsZCA8aT53b3JrPC9pPiB3aXRoIHlvdXIgbWluaW1hbCBjaGFuZ2Us IGJ1dA0KPGk+YWxzbzwvaT4gYWxsb3cgdGhlIHNlcnZlciB0byBzZW5kIG5vIGFkZHJlc3MgaW4g dGhlIG9mZmVyLiBUaGF0IHdheSB5b3UgY2FuIGltcGxlbWVudCB0aGUgZnVsbCBjaGFuZ2UgYXQg eW91ciBsZWlzdXJlLCBidXQgd2Ugc3RpbGwgZ2V0IGEgZ29vZCBsb25nIHRlcm0gb3V0Y29tZS4m bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F5AAD5B722BD44749A1E1A97AFFE47FCciscocom_-- From nobody Mon Dec 9 06:48:48 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2F212004E; Mon, 9 Dec 2019 06:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTui589cyMbL; Mon, 9 Dec 2019 06:48:39 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9746612000F; Mon, 9 Dec 2019 06:48:39 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id s18so7350533pfd.8; Mon, 09 Dec 2019 06:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZzVqlG8ouo4GTuzIY/1A08hbBaBuhc19w6CwOY1i4cs=; b=r7MIPxqW58tqap5eNRHE3rjYEPsH6eg2mL+zHhsqdyckE1XXGj89ZVC1uXnTkntoOU p8laYsURXKWSQmCMW72y2AVguwy9UM6q+Dcv4kzHnbEYn1Vm8NKiFE8Sm4WCeh3kCOWc JRFJYoIroFsnDwSA5nMSizywlsayUj5bNHT5lU7+S/vXAjRyEoNcVXYCm+V78hm9/zLw 7oT2+9d1zcODfw61vrAXuG1qeabMGOtYJqOfO6yfBsRL63AlpSx5b7Nq8yvpK4XZkNBJ CS6b59RvR61ODqXjgpaHaoICygRIMICz4zl+BzMtMylXwSZTRs0+6TkFVbngbdRSeDcZ X7/w== 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=ZzVqlG8ouo4GTuzIY/1A08hbBaBuhc19w6CwOY1i4cs=; b=ucW6ce5aqauODeY2j89zQYr0oEnTbvu45EswBndsUZJrCg9Rl4dj4EPk8WHRYR/A41 pEY72zIRFspyGVozbDK7XAXnBHeA8n5Y2Sbj7Wey+HfZbmsJOdjsmrjbzVaejUN5ZXXg OUqzh6IQfU3kMUewYRZbA08NWjjXXpf8OwfHJR0aBS5yqmEdszzkaTdW0z4XxNps3nty /b71ShEx/TFCI9DXeUUPxSO48XOMDp4zKxhNOwp2FNv91m+jrx7neFG+YKOWWG0BsXok GgjB+EU4B7sbp+gHAJosB3d+AnhTSS1F54ejMKdeIqbpLDOAcQUwlSJqZrLjOn3OoJF7 d0Qg== X-Gm-Message-State: APjAAAVH4CZQ3+kJ9nRBE/aeJe510LhFTov2XnvDv4YF/5a9f+vuSFlZ icSgS0iVc9J98Jb7MsNhVWc= X-Google-Smtp-Source: APXvYqwWxfinaU2rBB1iB4TDEuaH9KVpHJ0FPwFo5jPEhQEWmUJkuTyCN4arS4RM12fPsJXTw8KjCw== X-Received: by 2002:a62:2f06:: with SMTP id v6mr30082558pfv.105.1575902918959; Mon, 09 Dec 2019 06:48:38 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::1011? ([2600:8802:5900:13c4::1011]) by smtp.gmail.com with ESMTPSA id j1sm4675357pff.107.2019.12.09.06.48.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 06:48:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Fred Baker In-Reply-To: Date: Mon, 9 Dec 2019 06:48:37 -0800 Cc: dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: <61298ABE-88BC-4E47-A807-38E134981E85@gmail.com> References: To: Jen Linkova X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 14:48:41 -0000 Sorry for the delay in following up. This is an active thread. > On Dec 4, 2019, at 3:26 PM, Jen Linkova wrote: >=20 > On Thu, Dec 5, 2019 at 7:49 AM Fred Baker = wrote: >>> One of the biggest issue in deploying IPv6-only LANs is how to do it >>> incrementally, when some hosts work just fine in NAT64 environment >>> while some legacy devices still need IPv4. >>=20 >> A general comment - I don't think this is "devices" as much as it is = "applications". I'm thinking here of issues raised in RFC 2993 among = others. >=20 > You are right, it's applications getting broken w/o IPv4 indeed. The > text is saying 'devices' just for the sake of brevity: as a network > engineer I see *devices* connecting to the network, and IPv4 addresses > being assigned to the devices. A device just a box with a number of > applications (+ an OS) running inside. > However there are cases when an application needs an IPv4 address to > operate while the whole device does not. Think of a device with > 464XLAT enabled (e.g. an Android phone). The same application might > work perfectly fine on a mobile phone connected to an IPV6-only WiFi > but gets broken if I run it on my macbook connected to the same > network. >=20 > Would it be better if the sentence you quoted would be saying 'while > some legacy devices still need IPv4 addresses as their OSes and/or > applications depend on IPv4'? It might. I spent some time looking for the definition of "dual stack" (for = another reason), and found that while the term is used in some 94 = IPv6-related RFCs, it is never really defined. To me, and I think the = authors of those various RFCs, the implication is that one could turn = either IPv4 or IPv6 off, and peers using the remaining protocol would = still be able to use whatever service the device or application offers. = At my former employer, the term was generally used to mean that a system = was generally IPv4-capable but had some IPv6 capabilities as well. The = nearest thing to a definition that I found was in RFC 3750, but even = there one has to read it carefully. RFC 3750 makes the point about the OS offering either or both, but some = applications requiring IPv4, and of transitions being not only for the = OS, but for applications. >> I would argue that NAT64 is subject to the same issues as NAT44; = there is a coupling between the network and application layers in that = an IP address is used as an application layer identifier, and a coupling = between addressing domains in the network in that hosted applications = presume that an address they use is meaningful to and means the same to = an application in another domain. RFC 3439 talk about coupling primarily = in terms of time, but couplings such as I describe are also dangerous, = and I would argue that the issues raised in RFC 2993 are direct results = of coupling. So, whenever an address is embedded in application data and = interpreted or used by the peer application, there will be a NAT issue. >>=20 >> What would I want to do about it? I would not want to see an ALG (to = my mind, that works against higher layer security such as TLS or IPSec), = but rather see the application use an application layer identifier such = as a DNS name. >=20 > NAT64 is not perfect and is not a silver bullet but I do not think we > have any better tool right now. At least NAT64 is used for iPv4-only > destinations only so damage is contained (and the footprint will be > reducing over time, I hope). Speaking as a co-author of stateless IPv4/IPv6 NAT (which is about = connecting from {IPv4|IPv6} to {IPv6|IPv4}, and is used by NAT64, which = is about connecting statefully from an IPv6-only network to an IPv4-only = network), I would agree that neither stateless nor stateful IPv4/IPv6 = translation is a "silver bullet" - primarily due to issues raised in RFC = 2993. My co-authors wanted to not have to move all of their IPv4-only = servers to the IPv6-only network before being about to test it. They = wanted the evolving IPv6-only network to be able to access IPv4-only = servers on day 1, even though they had the full intention of making all = servers IPv6-capable over time, or duplicating them with IPv6-only = servers. Translation gave them the capability of getting there in a = limited fashion while they pursued the remainder of the process. The "better tool", if I understand RFC 2993 correctly, would be=20 (1) to remove network layer addresses from application layer = applications, so that there is no coupling between the application layer = and the network layer, or (2) make the application equally able to use IPv4 or IPv6 addresses, or (3) deploy separate instances of the application for use in IPv4 and = IPv6 networks.=20 Each has issues...=20= From nobody Mon Dec 9 06:58:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B049B12000F for ; Mon, 9 Dec 2019 06:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Khp_r5sMR84V for ; Mon, 9 Dec 2019 06:58:18 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D7E1200B6 for ; Mon, 9 Dec 2019 06:58:18 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id s64so537257pgb.9 for ; Mon, 09 Dec 2019 06:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8Vh5nhH1lUDKBMQt25+6cxJ7yrfseUvHXvfn3i4ZOBQ=; b=zr9Bjk7yzCo20JpXQikh1cUnsyCuTgEo12bpPTf1Hnrg37SKAbZzaSqFAFSxlwcklP JrGhCqV9Cvd2HJHgUBv8RcyRhGkxYXxySDJ6zDkuskbpJqToGnf2W5WP2D4pkgtagxOh UlvdEVlRHMblXvDl/ZTLuS6zT8Rh0A+3GBdwDakMEp4qWtk6meN95xgfhDAoY8ZyURI8 7dvL2fkHDAHlvQ3oH7LOwMu4itWxjwbPsQtXHGLdDPshTFOt0g+lNPNmvz8XFgcf4Tk+ Ohb8Pfi4Ohi/iMy+/04baWoWQdb19uAUAWGNP3o+ZzvxdTnJKGDOqPCyMPKug+LEY0r4 nO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8Vh5nhH1lUDKBMQt25+6cxJ7yrfseUvHXvfn3i4ZOBQ=; b=OSNCvIyf3NX4JdNAdbVjx/Ia5D7qd0x2maS1sUJ4CTd4fMHIhF6Pwsx48eBHY9g6Je ue9N4XnlAKT7Ac0oe53NgmWRx4JR4tagZT6xPlmqyZbxa+byccltLBb6HUaaXLavrX7M zst9To3mUKUU+uk3K7lJBkj+FvYzWADLiZ8ESp3rFbTcAhAOiGZBT4+9cWY5M7sCOVKL D27D2umfBaxMwKQGvJcFZDVh7b64LDZWbPjYiucFzfVCqQPTVgh7j7Txw39wtimYWhrN LMlkQ9E+yFW2ckaozedTInNmfNoJDeo1x4PY0bmiTz/R/nEvO+gqv6UCQq6MtLvp6m7U 2gCA== X-Gm-Message-State: APjAAAWoGX6uCu206pP381Skmzgaj6YPOfiiHMOPpvDz2ZY1t0ngCGVy UqQ1PFstqZt+p7rM0KTiNNyr/A== X-Google-Smtp-Source: APXvYqwZQ0vqwP6l/LUWiy5vLcAKhE2DQxEMfVZLSf5J0nYwXaaYfqqbX6C6pmwZ1ShDkrdgtsbHmQ== X-Received: by 2002:a63:6704:: with SMTP id b4mr19609101pgc.424.1575903497366; Mon, 09 Dec 2019 06:58:17 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id j18sm25321492pgk.1.2019.12.09.06.58.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 06:58:16 -0800 (PST) From: Ted Lemon Message-Id: <0E2261B8-032E-43C2-ABFE-4D68A4E47FD3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF636303-767E-4706-8711-5C9CFDC782A1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 06:58:15 -0800 In-Reply-To: Cc: Lorenzo Colitti , V6 Ops List To: "Bernie Volz (volz)" References: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 14:58:21 -0000 --Apple-Mail=_DF636303-767E-4706-8711-5C9CFDC782A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2019, at 6:31 AM, Bernie Volz (volz) wrote: > No, I am strongly arguing for no change. Yes, but why? My concern here is for the end state in ten years. In ten years, it = should be the case that virtually every client supports this feature, = and virtually every network offers it. We don=E2=80=99t want there to = be a DHCPv4 server on this network at all. What we want is a dumb = little thing sitting in the router on the link that, when it gets a = DHCPDISCOVER, immediately responds with a directive to use IPv6. So I = want to optimize for what that little stub should look like, /not/ what = your solution should look like now. I think it=E2=80=99s pretty clear that that little stub should not offer = an IPv4 address at all. What is the utility of offering one? We=E2=80=99= ve seen several proposed hacks for this, but they are just that: hacks. = They are additional complexity we don=E2=80=99t need. So that leads me to want you to think really hard about why you want to = do something else, and not just strongly argue for no change. Would = you mind doing that? It=E2=80=99s quite possible that there is some = problem with what I=E2=80=99m proposing that you haven=E2=80=99t yet = articulated, because you=E2=80=99re satisfied by the superficial answer. = It would be nice to figure out why, for example, the compromise I = proposed is unacceptable to you. What is bad about that solution? You = could, if you chose, make no changes to your server forever, and I could = implement my trivial stub in the router, and I think we=E2=80=99d both = be happy. Why do you think we wouldn=E2=80=99t both be happy? --Apple-Mail=_DF636303-767E-4706-8711-5C9CFDC782A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 9, 2019, at 6:31 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
No, I am strongly arguing for no = change.

Yes, but why?

My concern here is for the end state in = ten years.   In ten years, it should be the case that virtually = every client supports this feature, and virtually every network offers = it.  We don=E2=80=99t want there to be a DHCPv4 server on this = network at all.   What we want is a dumb little thing sitting in = the router on the link that, when it gets a DHCPDISCOVER, immediately = responds with a directive to use IPv6.   So I want to optimize for = what that little stub should look like, /not/ what your solution should = look like now.

I= think it=E2=80=99s pretty clear that that little stub should not offer = an IPv4 address at all.  What is the utility of offering one? =   We=E2=80=99ve seen several proposed hacks for this, but they are = just that: hacks.  They are additional complexity we don=E2=80=99t = need.

So that = leads me to want you to think really hard about why you want to do = something else, and not just strongly argue for no change.   Would = you mind doing that?  It=E2=80=99s quite possible that there is = some problem with what I=E2=80=99m proposing that you haven=E2=80=99t = yet articulated, because you=E2=80=99re satisfied by the superficial = answer.  It would be nice to figure out why, for example, the = compromise I proposed is unacceptable to you.  What is bad about = that solution?  You could, if you chose, make no changes to your = server forever, and I could implement my trivial stub in the router, and = I think we=E2=80=99d both be happy.

Why do you think we wouldn=E2=80=99t = both be happy?

= --Apple-Mail=_DF636303-767E-4706-8711-5C9CFDC782A1-- From nobody Mon Dec 9 07:19:31 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B619E12000F for ; Mon, 9 Dec 2019 07:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CKZlInwq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DsoR3c+Y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZBeDzSaJ0kV for ; Mon, 9 Dec 2019 07:19:26 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD94120043 for ; Mon, 9 Dec 2019 07:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10401; q=dns/txt; s=iport; t=1575904765; x=1577114365; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iOJY/uTFfeit/6bpLfhNiRbCMwamdyWP5eZ3lbTEQgU=; b=CKZlInwqOqtCEwn0J8ecapU8PZ7wGK3zG1IDbHsRU9ZlWQIUUV3ZZZVD dVRhgBPL65Ktk8m/V7gBNJSES5fCNAQ/e0V5caIQhAHaO2LyTnyTxiMEA qVwHWaIbXS2oilJVQHmRflXweW46Skwfoak5FQBlCXDM/Jx5RQebgZUTK w=; IronPort-PHdr: =?us-ascii?q?9a23=3AAwJ0SREaGwwI4Tjun8NqrJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjlK/r4Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgCmZO5d/40NJK1kHQEBAQkBEQU?= =?us-ascii?q?FAYFtBQELAYFKUAWBRCAECyqEAoNGA4sBgjqTSIRiglIDVAkBAQEMAQEtAgE?= =?us-ascii?q?BhEACF4ICJDcGDgIDDQEBBAEBAQIBBQRthTcMhVMCAQMSER0BATcBDwIBCA4?= =?us-ascii?q?0AgICMCUCBA4FGweDAIF6TQMuAQKhJAKBOIhhdYEygn4BAQWCSoJGGIIXCYE?= =?us-ascii?q?2AYwXGoIAgTgMFIJMPoQzgyYygiyQJ4VQmGYKgi6VZhuaMqh1AgQCBAUCDgE?= =?us-ascii?q?BBYFoI4FYcBVlAYJBUBEUjGaDc4pTdIEojWkBAQ?= X-IronPort-AV: E=Sophos;i="5.69,296,1571702400"; d="scan'208,217";a="680715289" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 15:19:24 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xB9FJO9O009595 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 15:19:24 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:19:24 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:19:24 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 09:19:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UZMcytXeM9kAH2TsXn+HhsYV2YCjXodTZg3PzZT8TeIqjxuJXbbyegOpX7dZuoNSzXuM4ItnQ5yg+cPeQi00rVfYCE7fjpxUPlSP/AeEToGGBULmx97UaUdBRPjTTjSS26zrNBAKCNOKib/1hC5/2wX7MEenzTllQsddk8L0faYT9nOvP1/JM/Tq8pJRNmEakRQimhLgxu+WG/b04u4juM6w++UaATqw7BaMd2lJBAoT49HSoiUmQqqNtBcTYEIhZ73BrW/z95AEIMLV2cA6tr9MOHosqJFOGpuJzRJNHHIbNoyqcX9mEtUGkvJwaJebFvbLU+YqwT2QK5ztIx4K5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iOJY/uTFfeit/6bpLfhNiRbCMwamdyWP5eZ3lbTEQgU=; b=oKwLPaq6/Ros8xUeSNIHFBP7mzsgjxzKorol6yMJ5midW3u9v1MtNnUmTYpvuMnFh0RxLZ18/ouH6ABmuEdgswlJjsGtyqTGsXE9RaefzrrfAKY8MuPVFEog6oZdSelanHImtms47OO4PbqpncR2tiK5X6VRZ2CcoTdl1BfEStYM4TKrEQs2jODxGdLDlxH403Qh/yTAD+Pqzvj3xoFXLRzTmJ0P58Biu9kQYq+8puXY6I2Z4802NzGRTfeznA2tOvVDdqQdSBR35g1B2IZj2phHY8TW3I2vTkZwCWTtxUJfUf4ncLE881zgXvocsUgsDxRyg5WTL1/bC9BrKXcYVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iOJY/uTFfeit/6bpLfhNiRbCMwamdyWP5eZ3lbTEQgU=; b=DsoR3c+Ylxhk4QzEz9ks4OLwDZinODYadlWOfWuPv+W0FnH+JdvK8uYahxRjcS6yk2cdQXKz4vUhZfvITIB56WjYLUw0L83ed6mClUjn4VUeSSbSNjuoZQ/JVdPtBUDqIpHQutAD3StIKVIuJSuzqfFyDhJt22uFAWapQo1r2wo= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4156.namprd11.prod.outlook.com (20.176.124.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12; Mon, 9 Dec 2019 15:19:23 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 15:19:23 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Lorenzo Colitti , V6 Ops List Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrph2epYC8FtIKky3loNP84z23aex1NRpgAAEqwCAAAQjEIAADT4A Date: Mon, 9 Dec 2019 15:19:22 +0000 Message-ID: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [2600:1000:b00f:b0ad:6cd9:43c2:ae16:91b2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23f13af4-254c-48f3-a63a-08d77cbb2bd3 x-ms-traffictypediagnostic: DM6PR11MB4156: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(366004)(376002)(136003)(189003)(199004)(66476007)(76116006)(64756008)(66556008)(66946007)(66446008)(33656002)(81156014)(81166006)(2616005)(5660300002)(86362001)(2906002)(91956017)(54906003)(71200400001)(71190400001)(8936002)(316002)(8676002)(478600001)(6916009)(229853002)(6486002)(4326008)(6506007)(53546011)(186003)(36756003)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4156; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mRWc2k3/6Z4tkgtLCqGbUMAzaSoYbiUk93f4aBXLPjgNS5axGzhgvtrJvUCH7o/uqeoB/9THtIlhpm2Fia/bwoArWl0Rxn/NKPhwg8nvWWzNyePbhUEu4lhSvAPG9pvMfpzS0Cg+wB21E5SLvq4Ycw9NM/V5Fzfqy60UJ46Z22MFJ1oXWvhTuzb6JLMRqpHlRXJXQ6a5Ip5E92P3jU7iC3Wf7nf1pcbMgkJOrphbcl3NAB3wL2XfjiISYFPe9Flm8w6x/IlLqXd1eyy72cGULtkCXGI2mlKah0cDuYp0OIChGxKHwzoyHpZV9TmDbhlxTnLxvUtjfhNRndzLkt1DlNYWrg9R7bKGja/Q1wIwh0of9TsBLvRO9DWG6vFyrAhfZvye4NV3CWg0ksPmPSakQDjM5VbZm4CjYgNYZVjZH3WRPTNSa4gdxPA6BWiIgKAs x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1655AE1AEF2E4720BFBEFA512CC4D240ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 23f13af4-254c-48f3-a63a-08d77cbb2bd3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 15:19:23.0604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7cHPst/3RVfJNREBBVboOwRBnW8j9xdNuMTcvu3cEq9E/sxMM11batqD5p4daUiK X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4156 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:19:28 -0000 --_000_1655AE1AEF2E4720BFBEFA512CC4D240ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyBhcyBhIG1pZGRsZSBncm91bmQsIGRyYWZ0IGNvdWxkIGFsbG93IGEgc2VydmVyIHRv IHJldHVybiAwLjAuMC4wIGFzIOKAnGFzc2lnbmVk4oCdIGFkZHJlc3MgYW5kIHRoZW4gY2xpZW50 IE1VU1QgTk9UIHNlbmQgYSBESENQUkVRVUVTVC4NCg0KQnV0IEkgZG8gbm90IHNlZSB0aGlzIGFz IGJlaW5nIGEgcmVxdWlyZW1lbnQuDQoNCg0KV2hlbiByZXNwb25kaW5nIHRvIGEgREhDUERJU0NP VkVSIHRoYXQgcmVxdWVzdGVkIHRoZSBpcHY2LW9ubHkgb3B0aW9uIGluIHRoZSBQUkwgYW5kIHRo YXQgdGhlIHNlcnZlciBpbmNsdWRlcyBpdCBpbiB0aGUgREhDUE9GRkVSLCBhIHNlcnZlciBjYW4g ZWl0aGVyOw0KDQotIHJldHVybiBhbiBhZGRyZXNzIHRoYXQgaXQgaXMgd2lsbGluZyB0byBvZmZl ciBhIGNsaWVudCBzaG91bGQgdGhlIGNsaWVudCBwcm9jZWVkLiBPciwNCi0gTUFZIHJldHVybiB0 aGUgMC4wLjAuMCBhZGRyZXNzLCBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgTVVTVCBOT1QgcHJv Y2VlZCB3aXRoIERIQ1BSRVFVRVNULg0KDQotIEJlcm5pZQ0KDQpPbiBEZWMgOSwgMjAxOSwgYXQg OTozNCBBTSwgdm9sekBjaXNjby5jb20gd3JvdGU6DQoNCu+7v05vLCBJIGFtIHN0cm9uZ2x5IGFy Z3VpbmcgZm9yIG5vIGNoYW5nZS4NCg0KQWdhaW4sIHRoZSB0aGluZ3MgSSBzdWdnZXN0ZWQgYXJl IG9wdGltaXphdGlvbnMgaWYgeW91IGZlZWwgdGhlcmUgaXMgYSBuZWVkIHRvIHJlZHVjZSB0aGUg aW1wYWN0IGlmIGxvdHMgb2YgY2xpZW50cyBjb21lIG9ubGluZSBhdCBzYW1lIHRpbWUuIFlvdSBk b27igJl0IGhhdmUgdG8gZG8gYW55IG9mIHRoZXNlIHRoaW5ncy4NCg0KSWYgYSBzZXJ2ZXIgY29t bWl0cyBsZWFzZSB0byBkaXNrIHdpdGggZnVsbCBsZWFzZSB0aW1lIG9uIGFuIG9mZmVyLCB5ZXMg eW91IGhhdmUgdG8gY2hhbmdlIHRoYXQuIFJmYyAyMTMxIGFscmVhZHkgc3RhdGVzIHRoYXQgdGhp cyBpcyBhcHByb3ByaWF0ZSB0byBkbyAobm90IGNvbW1pdCwgdXNlIHNob3J0IHRpbWUgdG8gaG9s ZCBsZWFzZSkuDQoNClN1cmUsIHdlIGNhbiBkb2N1bWVudCB0aGF0IGFzIHNvbWV0aGluZyB0aGF0 IGlzIGEgY29uc2lkZXJhdGlvbiBpZiB5b3UgaGF2ZSBsb3RzIG9mIGNsaWVudHMgYW5kIG5vdCBt dWNoIGFkZHJlc3Mgc3BhY2UuDQoNClNlbmRpbmcgMCBhZGRyZXNzIGlzIGJhZDoNCi0gbWlnaHQg aW1wYWN0IG1pZGRsZWJveGVzDQotIGhhcyBpc3N1ZXMgaWYgb3B0aW9uIGhhcyBiZWVuIGhpamFj a2VkIGZvciBvdGhlciBwdXJwb3NlcyBhbmQgaXMgaW4gcHJsDQotIGRvZXNu4oCZdCBhbGxvdyBj bGllbnQgdG8gY29udGludWUgd2l0aCBsZWFzZSBpZiBpdCBjaGFuZ2VzIGl0cyBjb25maWd1cmF0 aW9uIGJldHdlZW4gZGlzY292ZXIgJiBvZmZlcg0KDQpBbmQgZXZlbiBpZiBhZGRyZXNzZXMgYWxs IHVzZWQsIHJldHJhbnNtaXNzaW9ucyB3aWxsIGFsbG93IGNsaWVudCB0byBldmVudHVhbGx5IHBy b2NlZWQuDQoNCi0gQmVybmllDQoNCk9uIERlYyA5LCAyMDE5LCBhdCA5OjE4IEFNLCBUZWQgTGVt b24gPG1lbGxvbkBmdWd1ZS5jb20+IHdyb3RlOg0KDQrvu78NCk9uIERlYyA5LCAyMDE5LCBhdCAw NjowMCwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4gd3JvdGU6DQoNCu+7v1dl IGFscmVhZHkgZG9u4oCZdCBjb21taXQgdG8gZGlzayBwZXIgcmZjMjEzMSBhbmQgdXNlIGEgc2hv cnQsIHR1bmVhYmxlIHRpbWUtb3V0LiBTbywgYWdhaW4sIHdlIGFyZSBhbGwgc2V0IHdpdGhvdXQg c2VydmVyIGNoYW5nZXMuDQoNCkRvZXMgcmZjMjEzMSBhY3R1YWxseSBzYXkgdGhhdD8NCg0KWW91 IGNhbiBhbHNvIGNsYXNzaWZ5IHRoZXNlIGRldmljZXMgaW50byBhIHNlcGFyYXRlIGNsaWVudCBj bGFzcyB0byByZWR1Y2UgdGltZW91dCBmb3IgdGhlbSAoc3VjaCBhcyB0byBhIGZldyBzZWNvbmRz KS4NCg0KDQpUaGF04oCZcyBhIHNwZWNpYWwgc2VydmVyIGNoYW5nZS4NCg0KQWdhaW4sIEkgc2Vl IG5vIG5lZWQgZm9yIHNwZWNpYWwgc2VydmVyIGNoYW5nZXMuDQoNCklmIGEgc2VydmVyIGRvZXNu 4oCZdCBwcm92aWRlIGZvciB0aGVzZSBtZWNoYW5pY3MsIHRoZSBzZXJ2ZXIgc2hvdWxkLiBCdXQg dGhpcyBpcyBjb25maWd1cmF0aW9uIGlzc3VlLCBub3QgcHJvdG9jb2wgaXNzdWUuDQoNClNvIHNl cnZlcnMgb3RoZXIgdGhhbiB5b3VycyBzaG91bGQgYmUgdGhlIG9uZXMgdGhhdCBoYXZlIHRvIGNo YW5nZT8gIDopDQoNClRoZSByZWFzb24gSSB0aGluayB0aGlzIG1lcml0cyBhIGNoYW5nZSBpcyB0 aGF0IHdlIGFjdHVhbGx5IHdhbnQgZGlmZmVyZW50IGJlaGF2aW9yLiBUaGUgY2hhbmdlIGlzIHRy aXZpYWwuDQoNCllvdSBhcmVu4oCZdCBhY3R1YWxseSBhcmd1aW5nIGZvciBubyBjaGFuZ2U6IHlv dSBhcmUgYXJndWluZyBmb3IgYSBjaGFuZ2UgdGhhdCBpcyBtaW5pbWFsbHkgaW5jb252ZW5pZW50 IGFzc3VtaW5nIGEgY2VydGFpbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbi4NCg0KVGhhdCBpcyBh IGdvb2Qgc2hvcnQgdGVybSBtb3ZlLCBidXQgdGhpcyBpcyBhIGxvbmcgdGVybSBzb2x1dGlvbi4g U28gSeKAmW0gYXJndWluZyB0byBkbyBpdCByaWdodC4NCg0KT25lIHdheSB0byByZXNvbHZlIHRo aXMgaW1wYXNzZSB3b3VsZCBiZSB0byBzcGVjaWZ5IGl0IGRvIGl0IHdvdWxkIHdvcmsgd2l0aCB5 b3VyIG1pbmltYWwgY2hhbmdlLCBidXQgYWxzbyBhbGxvdyB0aGUgc2VydmVyIHRvIHNlbmQgbm8g YWRkcmVzcyBpbiB0aGUgb2ZmZXIuIFRoYXQgd2F5IHlvdSBjYW4gaW1wbGVtZW50IHRoZSBmdWxs IGNoYW5nZSBhdCB5b3VyIGxlaXN1cmUsIGJ1dCB3ZSBzdGlsbCBnZXQgYSBnb29kIGxvbmcgdGVy bSBvdXRjb21lLg0KDQo= --_000_1655AE1AEF2E4720BFBEFA512CC4D240ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7265C9E763496648968EB44A4B79C2E8@cisco.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpQ ZXJoYXBzIGFzIGEgbWlkZGxlIGdyb3VuZCwgZHJhZnQgY291bGQgYWxsb3cgYSBzZXJ2ZXIgdG8g cmV0dXJuIDAuMC4wLjAgYXMg4oCcYXNzaWduZWTigJ0gYWRkcmVzcyBhbmQgdGhlbiBjbGllbnQg TVVTVCBOT1Qgc2VuZCBhIERIQ1BSRVFVRVNULg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnV0 IEkgZG8gbm90IHNlZSB0aGlzIGFzIGJlaW5nIGEgcmVxdWlyZW1lbnQuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hlbiByZXNwb25kaW5nIHRvIGEg REhDUERJU0NPVkVSIHRoYXQgcmVxdWVzdGVkIHRoZSBpcHY2LW9ubHkgb3B0aW9uIGluIHRoZSBQ UkwgYW5kIHRoYXQgdGhlIHNlcnZlciBpbmNsdWRlcyBpdCBpbiB0aGUgREhDUE9GRkVSLCBhIHNl cnZlciBjYW4gZWl0aGVyOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSByZXR1cm4g YW4gYWRkcmVzcyB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gb2ZmZXIgYSBjbGllbnQgc2hvdWxkIHRo ZSBjbGllbnQgcHJvY2VlZC4gT3IsJm5ic3A7PC9kaXY+DQo8ZGl2Pi0gTUFZIHJldHVybiB0aGUg MC4wLjAuMCBhZGRyZXNzLCBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgTVVTVCBOT1QgcHJvY2Vl ZCB3aXRoIERIQ1BSRVFVRVNULjxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPi0gQmVybmllPC9k aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5PbiBEZWMg OSwgMjAxOSwgYXQgOTozNCBBTSwgdm9sekBjaXNjby5jb20gd3JvdGU6PGJyPg0KPGJyPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJs dHIiPu+7v05vLCBJIGFtIHN0cm9uZ2x5IGFyZ3VpbmcgZm9yIG5vIGNoYW5nZS4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkFnYWluLCB0aGUgdGhpbmdzIEkgc3VnZ2VzdGVkIGFyZSBvcHRpbWl6 YXRpb25zIGlmIHlvdSBmZWVsIHRoZXJlIGlzIGEgbmVlZCB0byByZWR1Y2UgdGhlIGltcGFjdCBp ZiBsb3RzIG9mIGNsaWVudHMgY29tZSBvbmxpbmUgYXQgc2FtZSB0aW1lLiBZb3UgZG9u4oCZdCBo YXZlIHRvIGRvIGFueSBvZiB0aGVzZSB0aGluZ3MuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JZiBhIHNlcnZlciBjb21taXRzIGxlYXNlIHRvIGRpc2sgd2l0aCBmdWxsIGxlYXNlIHRp bWUgb24gYW4gb2ZmZXIsIHllcyB5b3UgaGF2ZSB0byBjaGFuZ2UgdGhhdC4gUmZjIDIxMzEgYWxy ZWFkeSBzdGF0ZXMgdGhhdCB0aGlzIGlzIGFwcHJvcHJpYXRlIHRvIGRvIChub3QgY29tbWl0LCB1 c2Ugc2hvcnQgdGltZSB0byBob2xkIGxlYXNlKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlN1cmUsIHdlIGNhbiBkb2N1bWVudCB0aGF0IGFzIHNvbWV0aGluZyB0aGF0IGlzIGEgY29u c2lkZXJhdGlvbiBpZiB5b3UgaGF2ZSBsb3RzIG9mIGNsaWVudHMgYW5kIG5vdCBtdWNoIGFkZHJl c3Mgc3BhY2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZW5kaW5nIDAgYWRkcmVz cyBpcyBiYWQ6PC9kaXY+DQo8ZGl2Pi0gbWlnaHQgaW1wYWN0IG1pZGRsZWJveGVzPC9kaXY+DQo8 ZGl2Pi0gaGFzIGlzc3VlcyBpZiBvcHRpb24gaGFzIGJlZW4gaGlqYWNrZWQgZm9yIG90aGVyIHB1 cnBvc2VzIGFuZCBpcyBpbiBwcmw8L2Rpdj4NCjxkaXY+LSBkb2VzbuKAmXQgYWxsb3cgY2xpZW50 IHRvIGNvbnRpbnVlIHdpdGggbGVhc2UgaWYgaXQgY2hhbmdlcyBpdHMgY29uZmlndXJhdGlvbiBi ZXR3ZWVuIGRpc2NvdmVyICZhbXA7IG9mZmVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5BbmQgZXZlbiBpZiBhZGRyZXNzZXMgYWxsIHVzZWQsIHJldHJhbnNtaXNzaW9ucyB3aWxsIGFs bG93IGNsaWVudCB0byBldmVudHVhbGx5IHByb2NlZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXYg ZGlyPSJsdHIiPi0gQmVybmllPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5PbiBEZWMgOSwgMjAxOSwgYXQgOToxOCBBTSwgVGVkIExlbW9uICZsdDtt ZWxsb25AZnVndWUuY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2IGRp cj0ibHRyIj5PbiBEZWMgOSwgMjAxOSwgYXQgMDY6MDAsIEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7 dm9sekBjaXNjby5jb20mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/PHNwYW4+V2UgYWxyZWFkeSBkb27igJl0 IGNvbW1pdCB0byBkaXNrIHBlciByZmMyMTMxIGFuZCB1c2UgYSBzaG9ydCwgdHVuZWFibGUgdGlt ZS1vdXQuIFNvLCBhZ2Fpbiwgd2UgYXJlIGFsbCBzZXQgd2l0aG91dCBzZXJ2ZXIgY2hhbmdlcy4m bmJzcDs8L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5Eb2VzIHJmYzIxMzEgYWN0dWFsbHkgc2F5IHRoYXQ/PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj5Z b3UgY2FuIGFsc28gY2xhc3NpZnkgdGhlc2UgZGV2aWNlcyBpbnRvIGEgc2VwYXJhdGUgY2xpZW50 IGNsYXNzIHRvIHJlZHVjZSB0aW1lb3V0IGZvciB0aGVtIChzdWNoIGFzIHRvIGEgZmV3IHNlY29u ZHMpLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5UaGF04oCZcyBhIHNwZWNpYWwgc2VydmVyIGNoYW5n ZS4mbmJzcDs8L3NwYW4+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPjxzcGFuPkFnYWluLCBJIHNlZSBubyBu ZWVkIGZvciBzcGVjaWFsIHNlcnZlciBjaGFuZ2VzLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+ PGJyPg0KPHNwYW4+SWYgYSBzZXJ2ZXIgZG9lc27igJl0IHByb3ZpZGUgZm9yIHRoZXNlIG1lY2hh bmljcywgdGhlIHNlcnZlciBzaG91bGQuIEJ1dCB0aGlzIGlzIGNvbmZpZ3VyYXRpb24gaXNzdWUs IG5vdCBwcm90b2NvbCBpc3N1ZS48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YnI+DQo8L2Rpdj4NCjxkaXY+U28gc2VydmVycyBvdGhlciB0aGFuIHlvdXJzIHNob3VsZCBiZSB0 aGUgb25lcyB0aGF0IGhhdmUgdG8gY2hhbmdlPyAmbmJzcDs6KTwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhlIHJlYXNvbiBJIHRoaW5rIHRoaXMgbWVyaXRzIGEgY2hhbmdlIGlzIHRo YXQgd2UgYWN0dWFsbHkgPGk+d2FudDwvaT4gZGlmZmVyZW50IGJlaGF2aW9yLiBUaGUgY2hhbmdl IGlzIHRyaXZpYWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Zb3UgYXJlbuKAmXQg YWN0dWFsbHkgYXJndWluZyBmb3Igbm8gY2hhbmdlOiB5b3UgYXJlIGFyZ3VpbmcgZm9yIGEgY2hh bmdlIHRoYXQgaXMgbWluaW1hbGx5IGluY29udmVuaWVudCBhc3N1bWluZyBhIGNlcnRhaW4gZXhp c3RpbmcgaW1wbGVtZW50YXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0 IGlzIGEgZ29vZCBzaG9ydCB0ZXJtIG1vdmUsIGJ1dCB0aGlzIGlzIGEgbG9uZyB0ZXJtIHNvbHV0 aW9uLiBTbyBJ4oCZbSBhcmd1aW5nIHRvIGRvIGl0IHJpZ2h0LiZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+T25lIHdheSB0byByZXNvbHZlIHRoaXMgaW1wYXNzZSB3b3VsZCBi ZSB0byBzcGVjaWZ5IGl0IGRvIGl0IHdvdWxkIDxpPndvcms8L2k+IHdpdGggeW91ciBtaW5pbWFs IGNoYW5nZSwgYnV0DQo8aT5hbHNvPC9pPiBhbGxvdyB0aGUgc2VydmVyIHRvIHNlbmQgbm8gYWRk cmVzcyBpbiB0aGUgb2ZmZXIuIFRoYXQgd2F5IHlvdSBjYW4gaW1wbGVtZW50IHRoZSBmdWxsIGNo YW5nZSBhdCB5b3VyIGxlaXN1cmUsIGJ1dCB3ZSBzdGlsbCBnZXQgYSBnb29kIGxvbmcgdGVybSBv dXRjb21lLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_1655AE1AEF2E4720BFBEFA512CC4D240ciscocom_-- From nobody Mon Dec 9 07:21:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64B01208BB for ; Mon, 9 Dec 2019 07:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 m6Mk0ME6vHkA for ; Mon, 9 Dec 2019 07:21:23 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F4012084C for ; Mon, 9 Dec 2019 07:21:23 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id x13so5934203plr.9 for ; Mon, 09 Dec 2019 07:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U7bUaKdZvrWJIGyy9Qts5rIbST2j48qWG+8oAiI5U3g=; b=UyzztbFo1RqDsqqREH6xFoOSjKGkWxWiFKRIWtE4YjU4tfmIpVvC4pown8h0MXt59a 75APRTb48/x5Yto1sI7GT81K+LRs4KdM912d0lWeyehyH5gNOfmddh1NXnT0SdmlEQmg ePlQy+FpMzIgmr10C5/eiKetDkAUZP2RA++qc7pH1of6lpr+TTd229NlF+8v09+Uqcg/ OSlAlvNjB5SsAzDvnUcGBr8tSZwgXqL1g93pVxK6yJyKMeg8LTfEYvLfipHy8DigoqY+ OxSL8ywsw6+j+3qA1ApamshsL0VxqIePf4df+jHnUes7+9XE4ulpszmiT85h5i0JyC4u ZSQQ== 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=U7bUaKdZvrWJIGyy9Qts5rIbST2j48qWG+8oAiI5U3g=; b=t5JkHlKiJx1dDJVtDk5ZTy/jFb+mRv2w2UtTw/U1b+1d8X9qEtZNmD0GVB6RRN0pzU WqPyYGZry8Krhmni4TYlS4S1ZAlo0sbYRr5U4mtSyCUoU8AGeGWVhinT4vQgElEhjnDk BlbvYZTZfmbyYU/X4OMFTEK8md5UHxqnBQNVeuT3oW5Z7IW9OZLiP6ZiEZ29YuFrZfjs E6u8SnTIOTLY6HQMvcFgwrAs1ALn1Q45BHbHAag4+C2lnXhR027pYIhZsl6dCDe6EKeO ut+orXsqczj5tOkPOFq8PpKoiAXSCNGrnYiyetMnvGNEreGjF47JCWmjD0BM5+NoM8wX FhFA== X-Gm-Message-State: APjAAAXrL3QXk09Nw5dnbUdhnOq1uAPoNUODNeAP0eUHPs3ayhmoJA5n pWM095Kbm47WtrVcP2yQZR9NuZ18Fug= X-Google-Smtp-Source: APXvYqxvhfFtHr57YuMN4dsKCRjUeAx/pL4lMO4VwtqpaHj/CEQWWGtpIRg30OFPmRg5mKqg4SnhBg== X-Received: by 2002:a17:90a:bd10:: with SMTP id y16mr17113831pjr.108.1575904883072; Mon, 09 Dec 2019 07:21:23 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id l66sm25482302pga.30.2019.12.09.07.21.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 07:21:22 -0800 (PST) From: Ted Lemon Message-Id: <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E80ABA7E-033B-4FD8-9E9F-B01DCEDB627A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 07:21:21 -0800 In-Reply-To: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> Cc: Lorenzo Colitti , V6 Ops List To: "Bernie Volz (volz)" References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:21:25 -0000 --Apple-Mail=_E80ABA7E-033B-4FD8-9E9F-B01DCEDB627A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2019, at 7:19 AM, Bernie Volz (volz) wrote: > Perhaps as a middle ground, draft could allow a server to return = 0.0.0.0 as =E2=80=9Cassigned=E2=80=9D address and then client MUST NOT = send a DHCPREQUEST. > But I do not see this as being a requirement. This isn=E2=80=99t a middle ground. This is (at best) meaningless = behavior: a hack. Worse, it could actually cause problems with = middleboxes because they might try to treat 0.0.0.0 as a real address. = Why are you doing the hack? What is the problem you are trying to = prevent by doing the hack? --Apple-Mail=_E80ABA7E-033B-4FD8-9E9F-B01DCEDB627A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 9, 2019, at 7:19 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
Perhaps as a middle ground, = draft could allow a server to return 0.0.0.0 as =E2=80=9Cassigned=E2=80=9D= address and then client MUST NOT send a DHCPREQUEST.
But I = do not see this as being a requirement.

This isn=E2=80=99t a middle ground.  This is (at = best) meaningless behavior: a hack.   Worse, it could actually = cause problems with middleboxes because they might try to treat 0.0.0.0 = as a real address.   Why are you doing the hack?   What is the = problem you are trying to prevent by doing the hack?

= --Apple-Mail=_E80ABA7E-033B-4FD8-9E9F-B01DCEDB627A-- From nobody Mon Dec 9 07:21:55 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D3120089 for ; Mon, 9 Dec 2019 07:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 wmLA9ShpSaOe for ; Mon, 9 Dec 2019 07:21:50 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E181D1200DF for ; Mon, 9 Dec 2019 07:21:44 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id u7so15145570iop.5 for ; Mon, 09 Dec 2019 07:21:44 -0800 (PST) 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=R9h6oN/d1rczobMUpjEPcArNlO5oc2NXRRj7wW13s5k=; b=GKnev+DhMzDe82tGegbLRd5BGw12AAOm/35xgOJLvKzCeRwY0cCMi4tV8m4H8iDEOR OCYSpNq+/S12GJaAl5YwlCn5DmH6LNxDNfEgaLSVhRoE/F1DllyhBkJHnuldxr2JYHRF +YjhRJelTTgw/A1dch7rp7NmTFbhCzDXW5XWciP6DJkfmPVZdMIq/ajEPWk82fK5znCp YzpTR90EOTbyO60zr3kKH9MuMnM3e0EwBPQpUHXUDgs5ZArjajyNNqoFgiMM4AA4SmMw xbypJs6EmL/1xbbm63TZwfd/FMLZwNvsnzXwMzAeWN5Uvvzqjss0M0lBy6yNvXrbfyBo /suA== 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=R9h6oN/d1rczobMUpjEPcArNlO5oc2NXRRj7wW13s5k=; b=B3E0dy+VD0ITnolL9SZJtOqI40vrrE+1EEUextD/wYwNqdZaDW59mzobzkFVpRx1c4 R77rEg1Vxi6mP38zbLzoJ3C96wvv6to5u/4wxopVx3qnYAKRZwOwkoktsGZHzESNmO6W gMn6hyI6ic7EuQ5OFU3L6mw45cgCpferiI541LJQsniBFv3zI9NoOWbZ7JCJhmPvjo0y 5VQL1ZAYvOl+xtvN7iKxpGVSAFnWwLu9rTIAV8R/C1dQO72BztjmTapIOJ2YT4drULVQ +e9M5Uwg8t5GSTw0tQcekmRzcHU+98wcKEww1kP3z/BGp23zalFVi0cp1N7Mt0+CwvDP h/Dw== X-Gm-Message-State: APjAAAVDePpegzxkq4kN8CeUc5RzxhbUWFkluZGRc9IWy4iv+4mbYN77 jAAnOyWnoMLMFioz94Qrb3qn54cRgtYb4lF9CTw6BQ== X-Google-Smtp-Source: APXvYqxaR2np+/PVByrWMl42vYnA0N5JPPoSRMWGPhSsK9pSZry6BSpJaFv6D7pdubX6OI/ArXg9gNVl28c7rcV95bg= X-Received: by 2002:a02:3406:: with SMTP id x6mr20919395jae.46.1575904903840; Mon, 09 Dec 2019 07:21:43 -0800 (PST) MIME-Version: 1.0 References: <9102C9A8-DA3A-4460-88AD-13E24561B901@cisco.com> In-Reply-To: From: Lorenzo Colitti Date: Tue, 10 Dec 2019 00:21:32 +0900 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , V6 Ops List Content-Type: multipart/alternative; boundary="000000000000fefd0b059946f3c9" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:21:52 -0000 --000000000000fefd0b059946f3c9 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 9, 2019 at 11:17 PM Ted Lemon wrote: > One way to resolve this impasse would be to specify it do it would *work* > with your minimal change, but *also* allow the server to send no address > in the offer. That way you can implement the full change at your leisure, > but we still get a good long term outcome. > >From the perspective of a host OS developer and not a server developer, that seems like a good compromise. I hadn't thought of the "I just want a little stub on my network" argument. Though I'd wager it will be more than ten years before every network has one of those, it does seem like a nice minimalist approach especially good for small/home networks where we don't expect there to be any middleboxes to choke on an offer for 0.0.0.0. If we want hosts to support this (and we do, because otherwise even on such networks hosts might choke on the offer for 0.0.0.0) it should be in the document from day one and we should say that if the host gets 0.0.0.0 in the offer and a v6only-preferred option it MUST operate in IPv6-only mode and MUST NOT send a request for the address. Presumably what happens if the host gets 0.0.0.0 in the offer and no v6only-preferred option is left to the implementer. Just as a data point, the Android implementation will ignore it and continue to send discover packets. At the moment I can't remember why I did that and I don't know what other implementations do. --000000000000fefd0b059946f3c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2019 at 11:17 PM Ted Lemon= <mellon@fugue.com> wrote:
One way to resolve this impasse would be = to specify it do it would work with your minimal change, but also= allow the server to send no address in the offer. That way you can imp= lement the full change at your leisure, but we still get a good long term o= utcome.=C2=A0

From the perspect= ive of a host OS developer and not a server developer, that seems like a go= od compromise. I hadn't thought of the "I just want a little=C2=A0= stub on my network" argument. Though I'd wager it will be more tha= n ten years before every network has one of those, it does seem like a nice= minimalist approach especially good for small/home networks where we don&#= 39;t expect there to be any middleboxes to choke on an offer for 0.0.0.0.

If we want hosts to support this (and we do, becaus= e otherwise even on such networks hosts might choke on the offer for 0.0.0.= 0) it should be in the document from day one and we should say that if the = host gets 0.0.0.0 in the offer and a v6only-preferred option it MUST operat= e in IPv6-only mode and MUST NOT send a request for the address.
=
Presumably what happens if the host gets 0.0.0.0 in the offe= r and no v6only-preferred option is left to the implementer. Just as a data= point, the Android implementation will ignore it and continue to send disc= over packets. At the moment I can't remember why I did that and I don&#= 39;t know what other implementations do.
--000000000000fefd0b059946f3c9-- From nobody Mon Dec 9 07:24:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5A120233 for ; Mon, 9 Dec 2019 07:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 pk8AUPC8rlVL for ; Mon, 9 Dec 2019 07:24:37 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BD2120241 for ; Mon, 9 Dec 2019 07:24:37 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id a22so177322ios.3 for ; Mon, 09 Dec 2019 07:24:37 -0800 (PST) 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=yMIuemdC0QL/tdQwE4zk3D/1noZv+8grrVgJTDLTb7w=; b=k99+mzfKDted1PD99LAcf21iOT1Hq8BWmtGF6lwQvRnWSnrVrovvM9+ATM5Ngp8f/d 48xlLeW5k3oiVKqx8oNc1GCVdgMiF+EdE/Uh0DhFWd9IyH+EDpvjoTiK6+dOgkpbfHYN x0PdgKjIXRAvqfr7lZTUh8KSwWWBvPsDiBoYt4g2ILcGCgx/BbwNg46s8H1M13BUZ6/7 N6Pq7AsC52jvvhT7mYrQF7vyrmgt4KPrrJgNseJeRiKV65pA+l6Zgudw/dM5tlxZxywo loMINRQ7xEtemoPWg2gCckThJ+iyhdmuAoz7hSe1KdjGM3Qj9vPSDBLvCNsoQUklrBaN lgTw== 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=yMIuemdC0QL/tdQwE4zk3D/1noZv+8grrVgJTDLTb7w=; b=OkEHcHrimGPnq64WcskKEAnop0BTp4cAsSn/2dAKTax/HcZpROntHC2iw+CHQujQr5 imJ/qp37u/3VcLUCI++MkC0Dl5iZi19r54AZBZFGNIEwuQbfdZyEdEAtQKDjak2a1koN 0qrvkHwLhI1BYSGmCkDmJhWNvdDb+ZQw6kTaVGnRhcMJu/yuSlP255PTnN5vmIMKco9Y qz668eA0xST5EBWv/jxIc1gxVeV1xHeN2UhrULnFwW+p97+Eef8z/frABPHjIavK9zLT cO2acVzPpFSLOMrQXHNJLI6X9E4PcuhkX1zW0qqc651AW+wJKVEAtRmcmFuJ1+BiQO7e xc3Q== X-Gm-Message-State: APjAAAVDPWKca9QD7tD9JBV9VRpq/hcp1jVKLP2lHVSZfq5iQw2vFCRE ofxs5v6RpDVKP2UG/w+CTUrkv4MJZdWZUpJ+nU0LQA== X-Google-Smtp-Source: APXvYqzb3DpOR2l1pX7pK3CVbGPIlkrWj042cZvRcTKcwZ32yOhXn7IlPJylQa9pfNLBbPlusGMdwwIwyvxEdG230hA= X-Received: by 2002:a6b:3105:: with SMTP id j5mr1826203ioa.170.1575905076169; Mon, 09 Dec 2019 07:24:36 -0800 (PST) MIME-Version: 1.0 References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> In-Reply-To: <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> From: Lorenzo Colitti Date: Tue, 10 Dec 2019 00:24:24 +0900 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , V6 Ops List Content-Type: multipart/alternative; boundary="00000000000044558b059946fe3d" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:24:39 -0000 --00000000000044558b059946fe3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2019 at 12:21 AM Ted Lemon wrote: > Perhaps as a middle ground, draft could allow a server to return 0.0.0.0 > as =E2=80=9Cassigned=E2=80=9D address and then client MUST NOT send a DHC= PREQUEST. > But I do not see this as being a requirement. > > > This isn=E2=80=99t a middle ground. This is (at best) meaningless behavi= or: a > hack. Worse, it could actually cause problems with middleboxes because > they might try to treat 0.0.0.0 as a real address. Why are you doing th= e > hack? What is the problem you are trying to prevent by doing the hack? > Ted, I'm confused as to what you're proposing. I thought you were suggesting that the server would send back an OFFER with a yiaddr of 0.0.0.0. Is that not what you mean? --00000000000044558b059946fe3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2019 at 12:21 AM Ted Lemo= n <mellon@fugue.com> wrote:
Perhaps as a= middle ground, draft could allow a server to return 0.0.0.0 as =E2=80=9Cas= signed=E2=80=9D address and then client MUST NOT send a DHCPREQUEST.=
But I do not see this as being a requirement.

This isn=E2=80=99t a middle ground.=C2=A0 Th= is is (at best) meaningless behavior: a hack. =C2=A0 Worse, it could actual= ly cause problems with middleboxes because they might try to treat 0.0.0.0 = as a real address. =C2=A0 Why are you doing the hack? =C2=A0 What is the pr= oblem you are trying to prevent by doing the hack?
=

Ted, I'm confused as to what you're proposing. = I thought you were suggesting that the server would send back an OFFER with= a yiaddr of 0.0.0.0. Is that not what you mean?
--00000000000044558b059946fe3d-- From nobody Mon Dec 9 07:33:23 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1910C12000F for ; Mon, 9 Dec 2019 07:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Val4y3VtvMn for ; Mon, 9 Dec 2019 07:33:14 -0800 (PST) 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 09608120089 for ; Mon, 9 Dec 2019 07:33:13 -0800 (PST) Received: from [192.168.1.101] (host-79-121-42-138.kabelnet.hu [79.121.42.138]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id xB9FX51C024324 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 9 Dec 2019 16:33:11 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-138.kabelnet.hu [79.121.42.138] claimed to be [192.168.1.101] To: v6ops@ietf.org References: <61298ABE-88BC-4E47-A807-38E134981E85@gmail.com> From: =?UTF-8?Q?G=c3=a1bor_LENCSE?= Message-ID: <20ec1082-0099-1bcb-6a0c-be8ca964b76e@hit.bme.hu> Date: Mon, 9 Dec 2019 16:33:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <61298ABE-88BC-4E47-A807-38E134981E85@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 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.138; helo=[192.168.1.101]; 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] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:33:17 -0000 On 12/9/2019 15:48, Fred Baker wrote: [...] > The "better tool", if I understand RFC 2993 correctly, would be > (1) to remove network layer addresses from application layer applications, so that there is no coupling between the application layer and the network layer, or MPT could do something like that. It could also be considered as an IPv6 transition technology, as it supports any IP version tunnel over (several) any IP version paths. Do you think that it could be useful for the above purpose? Please see our I-D: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-04 and our slides: https://datatracker.ietf.org/meeting/99/materials/slides-99-intarea-mpt-network-layer-multipath-library-00 Best regards, Gábor From nobody Mon Dec 9 07:37:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2351200E3 for ; Mon, 9 Dec 2019 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 b19CnSpoJwt8 for ; Mon, 9 Dec 2019 07:37:05 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C9F1200DE for ; Mon, 9 Dec 2019 07:37:05 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id 6so7319144pgk.0 for ; Mon, 09 Dec 2019 07:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OfgFKN/rD8CShiccPHMT62L+TWjTfNpK6zaoI8Hs5Wg=; b=pddOK9TDY1Z6VDtlAPXLNFLha77A1frDoMTdKOYPLcGSzziwEb6Sl2nmBN+LXtagtR 0CMxaJlKCWNJbMRb+nuJ4nndrQTgAbIeS4MelxxwmMwqGC8RZtA23AaDYN/eXOrlaW45 D4EAMf6NYx4vUTCuvIgx11PulkiOYXtzVUwb69T9xeJAL3/WRT3qJul3HqFYAGMKGk0K iYAX/HQfFu+WOaE9ol1UlI5Kfqyh91FYHTs0YBjlL2fjIV1YA4ISO5eWH/hup8pUZXDz SJZvV9qoCCDYSAQ1v0P9KmZnqf7KgElJuq9ENZuDrrmlqYzcXLQ/PSsviAYcozRqfBNu L1GQ== 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=OfgFKN/rD8CShiccPHMT62L+TWjTfNpK6zaoI8Hs5Wg=; b=pTDm0CrKJf1OJ1eUVjg0gq8SdLmytA0pUOazbR8BQQlt+U0Ml534W571HJbJJebFKQ 3FVMpWm2tNlJdCnE0zfk7Ay3zkjXkkPVF5IRNC7g+ju/7TSq3WBnLb7z910gAhZb1mCu Yf+IzITBrxF2bKIKvPnsR1bjzpaw9chPg1ps45R2mtEeDIR0s3guc63geb/NSQyh2VHs b3bJBROLYrhIIroJCOrZNnLxKhd3XvpGLQjCyItcHp7vpA7iLFmH8fPzmoQOn+PFPQsm woT/MZf38SYmbl3iA/DRiBCqyEvUwNE5w2Pr4yLig4byCqocn0m3PZL+I4yPgDIs1iyH C8VQ== X-Gm-Message-State: APjAAAUgjN77RLSCnRues9g7ggr+FDEYKRq/dF0A/Ei/iCQFSNZMnbKn ydoepmJizVR0ADIKbGKoZoM0Ig== X-Google-Smtp-Source: APXvYqyPueMrqQ+U68U1Zl3O6pvRR27RL5flzVg5kLzAcgeOxFawpOFYz7HHNYEwGcSiki5Iuvotjw== X-Received: by 2002:a62:b512:: with SMTP id y18mr29024346pfe.211.1575905824459; Mon, 09 Dec 2019 07:37:04 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id q6sm27889654pfl.140.2019.12.09.07.37.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 07:37:03 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31A3151C-7FB6-4E93-A2E3-182C7AFC0455" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 07:37:02 -0800 In-Reply-To: Cc: "Bernie Volz (volz)" , V6 Ops List To: Lorenzo Colitti References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:37:09 -0000 --Apple-Mail=_31A3151C-7FB6-4E93-A2E3-182C7AFC0455 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2019, at 7:24 AM, Lorenzo Colitti wrote: > Ted, I'm confused as to what you're proposing. I thought you were = suggesting that the server would send back an OFFER with a yiaddr of = 0.0.0.0. Is that not what you mean? Oh crap, you=E2=80=99re right. This is probably why Bernie isn=E2=80=99t = agreeing. I was confusing yiaddr and DHCP requested address. BTW, I=E2=80=99ve been arguing for using the parameter request list to = signal this option, and that is how it=E2=80=99s supposed to be used, = but I=E2=80=99m realizing that some clients may still not actually = correctly implement the parameter request list=E2=80=94this was always a = problem. And so these clients may be relying on the behavior they get = when they don=E2=80=99t send a PRL. So it might be better for the = client to send the option, rather than requesting it, and then the = server can reply back with it if the network is IPv6-preferred. --Apple-Mail=_31A3151C-7FB6-4E93-A2E3-182C7AFC0455 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 9, 2019, at 7:24 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
Ted, I'm confused as to what = you're proposing. I thought you were suggesting that the server would = send back an OFFER with a yiaddr of 0.0.0.0. Is that not what you = mean?

Oh = crap, you=E2=80=99re right.  This is probably why Bernie isn=E2=80=99= t agreeing.  I was confusing yiaddr and DHCP requested = address.

BTW, = I=E2=80=99ve been arguing for using the parameter request list to signal = this option, and that is how it=E2=80=99s supposed to be used, but I=E2=80= =99m realizing that some clients may still not actually correctly = implement the parameter request list=E2=80=94this was always a problem. =  And so these clients may be relying on the behavior they get when = they don=E2=80=99t send a PRL.   So it might be better for the = client to send the option, rather than requesting it, and then the = server can reply back with it if the network is = IPv6-preferred.

= --Apple-Mail=_31A3151C-7FB6-4E93-A2E3-182C7AFC0455-- From nobody Mon Dec 9 07:40:01 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3986120852 for ; Mon, 9 Dec 2019 07:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 FADZuLu_1FuA for ; Mon, 9 Dec 2019 07:39:58 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502A9120839 for ; Mon, 9 Dec 2019 07:39:58 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id b15so13085574ila.7 for ; Mon, 09 Dec 2019 07:39:58 -0800 (PST) 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=qQUZMGJNznP4gvvYQHbhyH5idrXwjMza5lCX4v2zXso=; b=gkJIFunuRWFMq0Pajhpr+cprdjT7TMmlY0BOcJyTJML1Gkx7cXFg+IVhMNlNXh5r6+ Jl5mvPZc56Z3TV5SPJ/AKQAMxnNHsiDMpHzUYdQdntu/rw8SXIqHtIrCJAnXnZdHhaGx aGPEH3daGL5xQZL4K0vQEM8BAOQjm3XdGafg7LN4VCJaWs4ahS8SDMnHMMY27NypPPx+ VOXSz71gpRw/lwNogAVohsAScfvhQsE4hFHZ1LYW0q0L5fs8XUi9/mwPBMOMLMlZv395 mHkfBiALQ9hNx25Z0oV+F7YS/62AOgc0cXjBEP8w3EtWNJzrUXsrffww4n4I48Kt8HBL zqdQ== 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=qQUZMGJNznP4gvvYQHbhyH5idrXwjMza5lCX4v2zXso=; b=Oqy5xEw+aYbw1DqmMA93gzuJw3eZF23Chq1iXyu5GZ66cfUSd6NGyKRYbjfKQUV3hQ xOI/KryZExZdKiBOxQbBSWNwDqaKASf12ZAvtTrCZ9pIl0ypZ4lGPSN2Jmt16PWlv1sz N2UVd++1RmjHiKQmRdJsXV4YcBhktPpWPy7F4qtmcb6BgEuEH2ADTygs+hiTcje32OSC 5jZDzTBP9nXfm8c/fqruyNF87Wt5pB9lN6+d/2A1x/q+TSC6ogjQSf1sAcs7yx4rut/I TnWFJZsmi9SOv9DmWFU8kTElENWbX+mDsmuuC/K6Jit36Utiy5yFzPRsJcOkpwp8josk 8dxg== X-Gm-Message-State: APjAAAWsxckznGcB37Ew1U0sluJ8VV5juh5XV24NcsX04/7SE6NATCMH UeETBgLKAw4zcjbTHigSQfSLYAoaf4s0vxrskLFFgQ== X-Google-Smtp-Source: APXvYqwm9ovNDwOtY4OeWFQ+LDx5aEJJRxHmdkNou4eP6KAu9ua7UGkcqnKOijosncnZEvDPCN40f1b1H0g8Fis+stA= X-Received: by 2002:a92:3b10:: with SMTP id i16mr30511749ila.170.1575905997354; Mon, 09 Dec 2019 07:39:57 -0800 (PST) MIME-Version: 1.0 References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> In-Reply-To: From: Lorenzo Colitti Date: Tue, 10 Dec 2019 00:39:46 +0900 Message-ID: To: Ted Lemon Cc: "Bernie Volz (volz)" , V6 Ops List Content-Type: multipart/alternative; boundary="0000000000002c7519059947356a" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:40:00 -0000 --0000000000002c7519059947356a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2019 at 12:37 AM Ted Lemon wrote: > BTW, I=E2=80=99ve been arguing for using the parameter request list to si= gnal this > option, and that is how it=E2=80=99s supposed to be used, but I=E2=80=99m= realizing that > some clients may still not actually correctly implement the parameter > request list=E2=80=94this was always a problem. And so these clients may= be > relying on the behavior they get when they don=E2=80=99t send a PRL. So= it might > be better for the client to send the option, rather than requesting it, a= nd > then the server can reply back with it if the network is IPv6-preferred. > Can we simply say that those clients cannot use this option, then? It seems unfortunate to say that well-behaved clients that do know how to use the PRL should have to add the option to their request packets outside the PRL. --0000000000002c7519059947356a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2019 at 12:37 AM Ted Lemo= n <mellon@fugue.com> wrote:
BTW, I=E2=80=99ve= been arguing for using the parameter request list to signal this option, a= nd that is how it=E2=80=99s supposed to be used, but I=E2=80=99m realizing = that some clients may still not actually correctly implement the parameter = request list=E2=80=94this was always a problem.=C2=A0 And so these clients = may be relying on the behavior they get when they don=E2=80=99t send a PRL.= =C2=A0 So it might be better for the client to send the option, rather tha= n requesting it, and then the server can reply back with it if the network = is IPv6-preferred.

Can we simpl= y say that those clients cannot use this option, then? It seems unfortunate= to say that well-behaved clients that do know how to use the PRL should ha= ve to add the option to their request packets outside the PRL.
<= /div> --0000000000002c7519059947356a-- From nobody Mon Dec 9 07:44:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0931200B6 for ; Mon, 9 Dec 2019 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5Uk_jEpkurXz for ; Mon, 9 Dec 2019 07:44:25 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380701200D5 for ; Mon, 9 Dec 2019 07:44:25 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id 2so7411208pfg.12 for ; Mon, 09 Dec 2019 07:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rC+goQvJLX769BTR63UcEePtq40vvb90gLDZsHUDV5g=; b=k+OE0A/j6M4+NMsB0LNKk/4HuWAnr9GmkHqjgS7HCdNBj6TBOpWSmf+9w07Pd0S+iV jPXi6SBDwkaYLbzBTcmwfmhKSSg0ao5OY+HENuMBFHkmpkRFrsXP/RuOyXO5tqjO63Y4 /wtG3kveV/UhYrhK29Bc2u0UOxX5/6rhcnOZnJac3LL53gg8smHcZ9H1h+E0ze+YW/zP hfPY3+QOs+6WfghnANSWuUIs3i8585y6Ne1Ym8eTYs3s+rutXvOsBwOt02bsMmiohA8d 2SPS2XZwhXDtUuB9hJ+JAhuKqlLUd7GQzrirdV6GURIXbT5RpBuAZA9uHXVJWyrLxQxe D5UA== 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=rC+goQvJLX769BTR63UcEePtq40vvb90gLDZsHUDV5g=; b=WrgFu4DXAgUabuZ1xCBbc5xxnNBSLZlFi4Z+HCb6SqiiGcxOrTvjea0wfgOfZc978d Q13T4bSGCO0avJD5ULObR9a7IT4FTD8EzPLDqOlcwdVncAcNEVZfa8C40UbDZP751MpX 5sbRJNmHhEy8vKzLTP1AVTuLhRq6wq/d+MHqo2KH9B/B0iYkYTROJj+PqV3yje2YCrLQ TZ41pro7WOUl8YX5x4+mVSz0s8X3Rj3PYjZdmIF/djZMY91o5jyIqaVw4YeNRTNIeQG8 rUqRvp66HV8/Z4KyKIYBNBFH9y+5AqV+2NL+3ftk/f/OksfdYQGECqxAGoIdNg++pMPV Tffg== X-Gm-Message-State: APjAAAWfhWQMgALuESgUzmQ4QL1Xg27O1AmbcJ6SAB3c8R4OUYdciCZS UotrhC9zTaquDZNMmeW/H3oSfQ== X-Google-Smtp-Source: APXvYqwsCTIVWDiQcMlz+xIQdLWqYUAnE9QQ7pDd9JQI1jZcaYT835wHfUC8zrNiYGmEqJps4xW5tQ== X-Received: by 2002:a63:647:: with SMTP id 68mr19349208pgg.202.1575906264702; Mon, 09 Dec 2019 07:44:24 -0800 (PST) Received: from [172.16.144.152] ([144.178.28.8]) by smtp.gmail.com with ESMTPSA id f9sm5919607pfd.141.2019.12.09.07.44.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 07:44:23 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3E96A52F-540E-4102-9C85-06FE08F641AB" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 07:44:22 -0800 In-Reply-To: Cc: "Bernie Volz (volz)" , V6 Ops List To: Lorenzo Colitti References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:44:27 -0000 --Apple-Mail=_3E96A52F-540E-4102-9C85-06FE08F641AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2019, at 7:39 AM, Lorenzo Colitti wrote: > Can we simply say that those clients cannot use this option, then? It = seems unfortunate to say that well-behaved clients that do know how to = use the PRL should have to add the option to their request packets = outside the PRL. The trouble is, I don=E2=80=99t know how prevalent this problem is. = Maybe it=E2=80=99s okay, though=E2=80=94just looking at my own desktop = computer, it definitely does seem to be sending a PRL. Does Android = also? --Apple-Mail=_3E96A52F-540E-4102-9C85-06FE08F641AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 9, 2019, at 7:39 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
Can we simply say that those = clients cannot use this option, then? It seems unfortunate to say that = well-behaved clients that do know how to use the PRL should have to add = the option to their request packets outside the = PRL.

The = trouble is, I don=E2=80=99t know how prevalent this problem is. =  Maybe it=E2=80=99s okay, though=E2=80=94just looking at my own = desktop computer, it definitely does seem to be sending a PRL.   = Does Android also?


= --Apple-Mail=_3E96A52F-540E-4102-9C85-06FE08F641AB-- From nobody Mon Dec 9 07:50:54 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0D312000F for ; Mon, 9 Dec 2019 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Hm4yiLiY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QqlwXmN2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIRFZSUJwtRy for ; Mon, 9 Dec 2019 07:50:51 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2F5120099 for ; Mon, 9 Dec 2019 07:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3503; q=dns/txt; s=iport; t=1575906651; x=1577116251; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+lZZ9uixgiMTeKLIPlS+kWmPPBe09mFepG5l9sZLbxI=; b=Hm4yiLiYS6HZzhrI3a+f5g0CXKuwOjHnDU9rMeWPUISW1jMvRgiYHHzw ZoNinR3qC9qaUSfpH8drn6gyB8wRKBcKbsEsr6cX05Qjr7CETBZ6qf2qR 1t2kHI0mpjPqKDKDohOC86/mpui8lkC/Zb0CfAinMFKXZu8iNdygnDd8i 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AdCHZ9B8k7fHI7f9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98Rmlk+B8qXIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBQBrbO5d/4YNJK1kHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BHC9QBYFEIAQLKoQCg0YDiwGWAoRiglIDVAkBAQEMAQEtAgE?= =?us-ascii?q?BhEACF4ICJDgTAgMNAQEEAQEBAgEFBG2FNwyFUwIBAxIRHQEBNwEPAgEIBAo?= =?us-ascii?q?xAwICAjAUEQIEDgUigwCBek0DLgECoUMCgTiIYXWBMoJ+AQEFhRAYghcJgTa?= =?us-ascii?q?MGBqCAIE4IIJMPodZMoIsjSWDAoVQmGYKgi6VZhuaMqh1AgQCBAUCDgEBBYF?= =?us-ascii?q?pIjeBIXAVZQGCQVARFFeMD4NzilN0gSiNaQEB?= X-IronPort-AV: E=Sophos;i="5.69,296,1571702400"; d="scan'208,217";a="389327058" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 15:50:50 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xB9FooXq015496 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 15:50:50 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:50:49 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:50:48 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 09:50:48 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dInXzczaoIUfrK0KEIOXY6xTjCDnjqc0Ux9VtnNGrcnFedYWDXWeKWqERcZclpSCh5EtJmFjn6RH5wsjzuvOnqGi0r39BIFIp0wDRFMYK413xVYr8ickEmrlDbqyV87GGCPA2Qt47+diXxfkbX0xCb0qfKXdCPoJa+VCv5StV9Qfi8b/FFs5HNhg53UCv+z0iVb492SD3hjRdWA8yLexnEA+MCjNJGQuMGJxO1xQ40dnUd1QwYtxBWdQdNwNGU9uvsSrKkcVcygpBXLSPfKs1OAHZI8Z560ELWffdjGTZNeQQDQIwDG2pAbnuqIDKZ6wuE+T0YLiZ4Ji+PWeOrdBDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lZZ9uixgiMTeKLIPlS+kWmPPBe09mFepG5l9sZLbxI=; b=Z1+yZmSx/jwVrCYpSs0yVk6KP45Xp9KmHB4Ul2bAsBykVxTpHImfkrdxP7dedS/GI3Q+PousGXrlXff4maJyzIhVcciLhZ8+J+d2Sed7VwhDDZpIJr/n38GKFuzjKQMw9Po5C2QX+TR1uX2XoFmg4dpKckoVlYdIGVuZD3kt31jIIb9F3gt2FB5CpLWAi11Ar5aESwf+5mCMhRtAtQaTCjqYdSjyTqc5XB7okKq2QaQd47WsG/pNY1qRRHyKCNThIOtmvOmfr4EJkHN3PBVmx11vPyMU4G4Xztx+/kK7MJXEh3zWpruszXUXFrAvnsHBA9V53fVJEOmSBNBSY50NYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lZZ9uixgiMTeKLIPlS+kWmPPBe09mFepG5l9sZLbxI=; b=QqlwXmN2RvfkHmoESCI4Rwk800XcYJPZGR7pyjvEJGKCsYxrlQq+BdHxd+G7nAuy+XPj6r1FrOSBhtz2ZuApF9zMCc4FV2X3aPgW42JhEuraGDTpnVJS/wZLswMI1IU0E8GinlzebyfJPSOg9FLnJc8UYA3MeUzHxWzOeNf7NgE= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4140.namprd11.prod.outlook.com (10.255.61.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Mon, 9 Dec 2019 15:50:47 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 15:50:47 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: Lorenzo Colitti , V6 Ops List Thread-Topic: [v6ops] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrph2epYC8FtIKky3loNP84z23aex1NRpgAAEqwCAAAQjEIAADT4AgAAAjoCAAADaAIAAA4cAgAAAxACAAAFJAIAAAcuG Date: Mon, 9 Dec 2019 15:50:47 +0000 Message-ID: <74934A64-D04E-49C1-94EC-71C0000070E6@cisco.com> References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [2600:1000:b00f:b0ad:6cd9:43c2:ae16:91b2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08deb607-e460-4e6b-1b67-08d77cbf8f0f x-ms-traffictypediagnostic: DM6PR11MB4140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(376002)(396003)(39860400002)(199004)(189003)(66946007)(5660300002)(54906003)(66446008)(76116006)(91956017)(66476007)(33656002)(64756008)(86362001)(478600001)(66556008)(6486002)(316002)(6916009)(6512007)(53546011)(6506007)(186003)(2616005)(2906002)(8936002)(4744005)(36756003)(229853002)(4326008)(81156014)(8676002)(71200400001)(81166006)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4140; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fQ5ZAlO9M5ild0+jUdZreS//jvZ3vuhwvzxqFMUOrxXqAMrpVN09rHaYYx4vMrSGsdspkfnXoXoDePZzxzZSJZwrsbEtTrSnaP2O0sP18AreMDBlHh1Y0vfayOYPL8x7L+RA+MIvToE98ibo/ucmZftRsu27IFXVNhYhTsoNKsaW/cqDUvET0Ex6dsjtAPxkLwcknd74sMln8JQYsq9EWBubf5u9tfbLtiuXGdvH0eWYcMkCnFZJ57FKV9EoceSXX7OUAtd9xdb3IGwHRUFvgkTO9NoKzDTGJyy/mvBIVxE58RavLDlG/5X14V+sQq/lNTC1nYIFri5ObqTorLpbiqRPrtSrOg2+An76ILVkg2qT9DlCQZh6bhJMzDUYhp4gvN728mSfDMbHp5FYAQpKwi8SyJ9oAxub9vROfuhPb0HjdNJDlSXsYPIZ/vcK0X+N x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_74934A64D04E49C194EC71C0000070E6ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 08deb607-e460-4e6b-1b67-08d77cbf8f0f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 15:50:47.4825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +J/KTMocIDsHJbwqe2OaWVhkDbjDTgJRX7RvgyCrajKVPFf0OWhF2hW9rcmRE+AE X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4140 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:50:53 -0000 --_000_74934A64D04E49C194EC71C0000070E6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgY2xpZW50cyBoYXZlIHRvIGNoYW5nZSB0byBzdXBwb3J0IHRoaXMsIGZpeCB0aGUgUFJMIG9w dGlvbiBoYW5kbGluZy4NCg0KLSBCZXJuaWUgKGZyb20gaVBob25lKQ0KDQpPbiBEZWMgOSwgMjAx OSwgYXQgMTA6NDUgQU0sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4gd3JvdGU6DQoNCu+7 vyBPbiBEZWMgOSwgMjAxOSwgYXQgNzozOSBBTSwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdv b2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KQ2FuIHdlIHNpbXBs eSBzYXkgdGhhdCB0aG9zZSBjbGllbnRzIGNhbm5vdCB1c2UgdGhpcyBvcHRpb24sIHRoZW4/IEl0 IHNlZW1zIHVuZm9ydHVuYXRlIHRvIHNheSB0aGF0IHdlbGwtYmVoYXZlZCBjbGllbnRzIHRoYXQg ZG8ga25vdyBob3cgdG8gdXNlIHRoZSBQUkwgc2hvdWxkIGhhdmUgdG8gYWRkIHRoZSBvcHRpb24g dG8gdGhlaXIgcmVxdWVzdCBwYWNrZXRzIG91dHNpZGUgdGhlIFBSTC4NCg0KVGhlIHRyb3VibGUg aXMsIEkgZG9u4oCZdCBrbm93IGhvdyBwcmV2YWxlbnQgdGhpcyBwcm9ibGVtIGlzLiAgTWF5YmUg aXTigJlzIG9rYXksIHRob3VnaOKAlGp1c3QgbG9va2luZyBhdCBteSBvd24gZGVza3RvcCBjb21w dXRlciwgaXQgZGVmaW5pdGVseSBkb2VzIHNlZW0gdG8gYmUgc2VuZGluZyBhIFBSTC4gICBEb2Vz IEFuZHJvaWQgYWxzbz8NCg0KDQo= --_000_74934A64D04E49C194EC71C0000070E6ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpB cyBjbGllbnRzIGhhdmUgdG8gY2hhbmdlIHRvIHN1cHBvcnQgdGhpcywgZml4IHRoZSBQUkwgb3B0 aW9uIGhhbmRsaW5nLjxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPi0gQmVybmllIChmcm9tIGlQ aG9uZSk8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pk9uIERlYyA5LCAyMDE5LCBhdCAxMDo0NSBBTSwgVGVkIExlbW9uICZsdDttZWxsb25AZnVndWUu Y29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/IE9uIERlYyA5LCAyMDE5LCBhdCA3 OjM5IEFNLCBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb20iIGNsYXNzPSIiPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5DYW4NCiB3ZSBzaW1wbHkgc2F5IHRoYXQgdGhv c2UgY2xpZW50cyBjYW5ub3QgdXNlIHRoaXMgb3B0aW9uLCB0aGVuPyBJdCBzZWVtcyB1bmZvcnR1 bmF0ZSB0byBzYXkgdGhhdCB3ZWxsLWJlaGF2ZWQgY2xpZW50cyB0aGF0IGRvIGtub3cgaG93IHRv IHVzZSB0aGUgUFJMIHNob3VsZCBoYXZlIHRvIGFkZCB0aGUgb3B0aW9uIHRvIHRoZWlyIHJlcXVl c3QgcGFja2V0cyBvdXRzaWRlIHRoZSBQUkwuPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoZSB0cm91YmxlIGlzLCBJIGRv buKAmXQga25vdyBob3cgcHJldmFsZW50IHRoaXMgcHJvYmxlbSBpcy4gJm5ic3A7TWF5YmUgaXTi gJlzIG9rYXksIHRob3VnaOKAlGp1c3QgbG9va2luZyBhdCBteSBvd24gZGVza3RvcCBjb21wdXRl ciwgaXQgZGVmaW5pdGVseSBkb2VzIHNlZW0gdG8gYmUgc2VuZGluZyBhIFBSTC4gJm5ic3A7IERv ZXMgQW5kcm9pZCBhbHNvPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_74934A64D04E49C194EC71C0000070E6ciscocom_-- From nobody Mon Dec 9 07:52:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC870120089 for ; Mon, 9 Dec 2019 07:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xPl_S8HsI2p2 for ; Mon, 9 Dec 2019 07:52:38 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AC1120043 for ; Mon, 9 Dec 2019 07:52:38 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id s10so5987197plp.2 for ; Mon, 09 Dec 2019 07:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ecJqDeZI/stzuJ9agM+Dul4IBgWEnOumAVq0+k8e1Xs=; b=evUgcCZuHPZwD5192BIYggwO/UbfoWLbFqA8AbIUhIJpO84xXwkSmjOFMu6BSGFsCj Sgrt9+76TF4evZ0lA75kFH0rYK9s7E05OVSdw/2wFIGYPbIovoMAOrHiaSzMafj0oWk6 lYGjOs4xkwM/C7pTsWUcIqTrb5xyJKh1TA1qNWwoKRA7uvDJWOY7iRQS7enm680SklIx VfvoJhKuxakkwjctFyT4VUV+kjWRG/oEkRp/7TubQmtvxuEvMps8ORQHCLv3MhXiwTNu w6ycXz2ETpavliUttNk6sULBK8mJWfLYfX2ZjaHiXx9f5cL0hfMnwrIW/F3gujTgq7NR fsSg== 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=ecJqDeZI/stzuJ9agM+Dul4IBgWEnOumAVq0+k8e1Xs=; b=Kv64Lei0VfGm0ugJCwVdTx6775bK4Qcofr3bcvNWouP3CmPix9E4vNlC38JLSO4Sni 2ScLAu71Z1UYLgm66I3YlCbMdoG788j/2NkWVPHdVABj8afRXJXWRVvIp7BEwe5uAcQb tg2xpjDpoHQ7WfHfb3p84CBEk6oaGr9KxSgpiZviee63n4rxkCM0DvfDm7NzpZ77RM9b j+0UrBNCGSmpOEZkC6IxiJWEbYQ3J1oyDhQIwsfHjUMQGSpRN9MsVVouvcNJvvCGKUKr qEzMxioXkTSxlaXf/a3JfP73o4fb+pDcSj+2EcHX4ua5cGW3HnGfM7T9Cmmoy+tZeo3P nBlA== X-Gm-Message-State: APjAAAXDMyJqkH5F2g5V6qE9vXYEf9yUkvXN/WokV1ijH5HCoGlC+W9i h6DvWrquwokWkvkrk57qtD+H4g== X-Google-Smtp-Source: APXvYqyYtTW89Fwk28lk0MwSnUb9YuTHfDg4aZ8d0gqVlh5zlEIs2/TCBnniTmO3cj0ccdvnlGt+rw== X-Received: by 2002:a17:902:9a92:: with SMTP id w18mr18997846plp.24.1575906758125; Mon, 09 Dec 2019 07:52:38 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id w131sm28261854pfc.16.2019.12.09.07.52.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 07:52:37 -0800 (PST) From: Ted Lemon Message-Id: <79DD33B9-6AF0-442C-807C-E35EF656DD24@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF48EF32-7CC4-444E-AE91-7E229FE06C10" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 07:52:36 -0800 In-Reply-To: <74934A64-D04E-49C1-94EC-71C0000070E6@cisco.com> Cc: Lorenzo Colitti , V6 Ops List To: "Bernie Volz (volz)" References: <1655AE1A-EF2E-4720-BFBE-FA512CC4D240@cisco.com> <85E7ECA2-3538-48D7-99CB-7E978E7C0F03@fugue.com> <74934A64-D04E-49C1-94EC-71C0000070E6@cisco.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 15:52:40 -0000 --Apple-Mail=_BF48EF32-7CC4-444E-AE91-7E229FE06C10 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Dec 9, 2019, at 7:50 AM, Bernie Volz (volz) wrote: > As clients have to change to support this, fix the PRL option handling. Okay, WFM. --Apple-Mail=_BF48EF32-7CC4-444E-AE91-7E229FE06C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 9, 2019, at 7:50 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
As clients have to change to = support this, fix the PRL option handling.

Okay, WFM.

= --Apple-Mail=_BF48EF32-7CC4-444E-AE91-7E229FE06C10-- From nobody Mon Dec 9 15:41:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11959120288; Mon, 9 Dec 2019 15:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8f7fDehRzal; Mon, 9 Dec 2019 15:41:01 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 E32851200F6; Mon, 9 Dec 2019 15:41:00 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id u17so17698629lja.4; Mon, 09 Dec 2019 15:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xOKqOG2GYq0jDkzK4c3nIs57/JEuxzfPzZkXvz9YJeU=; b=KTxZmlJMmuQG2mR8xrJYoNt/IF7mdnMQ/gagAfZELYoYCjIDMT4T40mnwJqlPt0h0h yfgwd8pWkfb8ysYj3J4gr0glcSwGvE9vRGGFPZdQfcjiCVIMXYLZ+XdnjlPgi6YagSR/ h+guw/bBpAy0ad/p1F+Xc66fHAHnC2QZ6TuTwUeoD74Ar6n7QTiv3K7O8h8PgHM2kSTs yeJkgy+JTBoSjMPWREbmSPx0NqBXHSYBLqmAGETkmAuKfmUC4FWiOtlwPwUwmRKwgZvD ASZh6kW1fZcq8mGlVZovOH0slKScQ7pA+CuCP7PNqWWD6nZ1FNCiT6snJTsRJU9Lc9fr olTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xOKqOG2GYq0jDkzK4c3nIs57/JEuxzfPzZkXvz9YJeU=; b=FTrw2BnVQktMNtx4QoWdIKtT386y9KSaiHzfFvcPKSbVG5c5VHbU1oRkxLETYrdXU/ 5+7p87NCwPug8YhqHTZyeD4CbhR+BDUN15T5umxVA8zjGTYd79n2GHOK0SLVBwYTsLcH R0DwYRBah2FImvbLlu3RV91XV8nNiXrkLFxvVO7k4igBM5NOKLrR6lLacUu1uMWt7QnR RYdS3veeSfiFKTSRe/LMNzjlLLOhsLypfq+4lFWKKke0UMyB24BhdJLe7Ju7MVhcW+CY CRQivccEHPs2twk3s3PGmpdP6UMsjR629nFrDDTiaKd0wSVW8b/ZfYloFV1dK5h2QeU+ K01w== X-Gm-Message-State: APjAAAX4XJRHHge20CazonI2k/GJoL5yembPLG1dOwj6tlPS5p8pOxKI f3vhA9iLh7dVPtj+X06286j/zGhLw05fMw== X-Google-Smtp-Source: APXvYqyprV3Tub8ry6Z1s0OcwCjRxx1IXdQwAW30/5OMLtWsB1vli8zV/C3QSQdTn9C/gB+yidmJNA== X-Received: by 2002:a2e:580c:: with SMTP id m12mr18304945ljb.150.1575934858862; Mon, 09 Dec 2019 15:40:58 -0800 (PST) Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.gmail.com with ESMTPSA id 2sm659083ljq.38.2019.12.09.15.40.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 15:40:57 -0800 (PST) To: Ted Lemon Cc: "dhcwg@ietf.org" , "v6ops@ietf.org" References: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> From: Tomek Mrugalski Message-ID: <27eb153c-4340-b79a-6c1e-6c15c9ff7b29@gmail.com> Date: Tue, 10 Dec 2019 00:40:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> Content-Type: multipart/alternative; boundary="------------9909805CE1EFC048B83C9023" Content-Language: en-US Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 23:41:03 -0000 This is a multi-part message in MIME format. --------------9909805CE1EFC048B83C9023 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06.12.2019 17:02, Ted Lemon wrote: > On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) > wrote: >> which requires fewer changes on the DHCP server implementation > > This is almost certainly not true.  In order for this to work, you’re > going to have to have some special-purpose code to support it.  Better > to do the clean solution than a hack that minimizes changes to the > server at the expense of more complication in the client-server > interaction. This part of the discussion seems to have been mostly settled. But in case it isn't, here's another opinion. As a DHCP server vendor, I'd very much prefer no code changes. For several reasons: 1. You can start using the option now, without any server upgrades, just tweak the server configuration to send one extra option. This is expected to be a significant factor in the adoption process. 2. The basic DHCPv4 mechanism of clients requesting options in PRL and the server sending them is decades old and there are tons of policy mechanisms around it (send only when requested, force sending to specific devices or class of devices, treat devices that request that option as a separate class, etc.) These are all well understood by network admins. 3. Extra logic requires extra testing. There may be incompatibilities, especially with firewalls and relays that attempt to track state. Some of them may be hard to detect. Having said that, I'm willing to implement code changes if I have to. Tomek --------------9909805CE1EFC048B83C9023 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 06.12.2019 17:02, Ted Lemon wrote:
On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
which requires fewer changes on the DHCP server implementation

This is almost certainly not true.  In order for this to work, you’re going to have to have some special-purpose code to support it.  Better to do the clean solution than a hack that minimizes changes to the server at the expense of more complication in the client-server interaction.
This part of the discussion seems to have been mostly settled. But in case it isn't, here's another opinion. As a DHCP server vendor, I'd very much prefer no code changes. For several reasons:

1. You can start using the option now, without any server upgrades, just tweak the server configuration to send one extra option. This is expected to be a significant factor in the adoption process.

2. The basic DHCPv4 mechanism of clients requesting options in PRL and the server sending them is decades old and there are tons of policy mechanisms around it (send only when requested, force sending to specific devices or class of devices, treat devices that request that option as a separate class, etc.) These are all well understood by network admins.

3. Extra logic requires extra testing. There may be incompatibilities, especially with firewalls and relays that attempt to track state. Some of them may be hard to detect.

Having said that, I'm willing to implement code changes if I have to.

Tomek --------------9909805CE1EFC048B83C9023-- From nobody Mon Dec 9 15:45:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A501120939; Mon, 9 Dec 2019 15:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUIrBr3kv-AP; Mon, 9 Dec 2019 15:44:48 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 58DF512081E; Mon, 9 Dec 2019 15:44:48 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id k8so17666794ljh.5; Mon, 09 Dec 2019 15:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uFP5WMIq590anFNYsIgQXLX8eMDSDmcpVlrGbBA3MIc=; b=OBSPXqWSKcsTW/+/NFWOqsOt4eBuG3rm5UH/Ye1Qyug6frSB2NOAjxJImWvAaJBJp3 DcmcmnINWG+nqLkXMyUsYV0sHUz+DkqzAZrfsvPMtdnAL0C91uWlHTevcCC/+HfaEBUx pMAY33rD2Rov+K3xEKExJ5VWC1+hlKU39xbIoLNXXNHzOuvtxo/q3uYbP/T2+HzsX3sD X4BCfREivUKbprKCDAEtYnUFvkGkK7eDZlpxybRxcZC3hcyKshI0nkSP86EhCCIdd/Z8 udrCelLgXDSZv7Ts9TldX4jvAYllyp0hssX8n7+045HODEsN1iUwzKZHuALuuWd9+SDI L7qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=uFP5WMIq590anFNYsIgQXLX8eMDSDmcpVlrGbBA3MIc=; b=nFtYcJ4qKnHXRTE+yo3D+loZ/BsqrlmzpjhqehMD/cG6WekesUSxjJSPFLlYdydqGG okti9zmxRqEwXniP3sSOgd5WXcwRNCeRwsHtIQ3UgQpTws/wMDAVSk7pI3vthY8EVHdR n8mRMtAxHAjb1KmkCPV2D2meRmti0K1oaXTXXP4TegXm4Ftlfu4vR6bt5vvL184YNiEU p6ocP/HrioTAbuFTdqUb7natsMX5Z5122Lvz0lXvWHhIDrP1AHhtC2DM1eMBdSM+T2id 1T1vjFNoPa/b/8BP5JzhT6U4hTHvg1DU+RxbTwcbRsMYIWjWHohPUzi4OizWIaHHMPix m6zQ== X-Gm-Message-State: APjAAAX8gN1ucebtuD/BNK2zTKPg8iuazcS0fRCExZlB5uP5rDUf1Smy 9W+7lTiLHZmDORl1ssMzOlfHcDr86x6JCA== X-Google-Smtp-Source: APXvYqwcjLuA87lrw8eRopRj029ducZNWYHHaau797/cj7gHOwcoecyItZ+/tA3/Eu64S6l10s6gkg== X-Received: by 2002:a2e:980b:: with SMTP id a11mr18259366ljj.189.1575935086603; Mon, 09 Dec 2019 15:44:46 -0800 (PST) Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.gmail.com with ESMTPSA id y23sm674765ljk.6.2019.12.09.15.44.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 15:44:45 -0800 (PST) To: "Bernie Volz (volz)" Cc: "dhcwg@ietf.org" , "v6ops@ietf.org" References: <8FD2BAAB-96D1-41F0-97A2-2D16CDAF999E@fugue.com> <1D8C9B8A-0F46-4B02-9402-2265F86D5F0F@cisco.com> From: Tomek Mrugalski Message-ID: <14cc41a1-caab-2ed9-15ba-999fbde39229@gmail.com> Date: Tue, 10 Dec 2019 00:44:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <1D8C9B8A-0F46-4B02-9402-2265F86D5F0F@cisco.com> Content-Type: multipart/alternative; boundary="------------C5082632EBB79AEE3C3BC554" Content-Language: en-US Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 23:44:53 -0000 This is a multi-part message in MIME format. --------------C5082632EBB79AEE3C3BC554 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06.12.2019 17:18, Bernie Volz (volz) wrote: > BV> I will say that one issue that could exist with this option that > is a bit unusual is that it is currently 0-length. We have only one > other zero-length option that I recall, and that is Rapid Commit > (which is client to server, not server to client). So, it is possible > that there are clients that are unhappy about zero-length options. Agree it's a valid concern. It could have affected some middleboxes (snooping relay, firewall tracking state etc.). Fortunately, it's going to be addressed in upcoming -01 rev. The option format is redefined to be 4 octets long and will contain a timer value. Tomek --------------C5082632EBB79AEE3C3BC554 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 06.12.2019 17:18, Bernie Volz (volz) wrote:
BV> I will say that one issue that could exist with this option that is a bit unusual is that it is currently 0-length. We have only one other zero-length option that I recall, and that is Rapid Commit (which is client to server, not server to client). So, it is possible that there are clients that are unhappy about zero-length options.

Agree it's a valid concern. It could have affected some middleboxes (snooping relay, firewall tracking state etc.). Fortunately, it's going to be addressed in upcoming -01 rev. The option format is redefined to be 4 octets long and will contain a timer value.

Tomek

--------------C5082632EBB79AEE3C3BC554-- From nobody Mon Dec 9 16:02:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF7E12021C; Mon, 9 Dec 2019 16:02:18 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi_0WFfLsdPh; Mon, 9 Dec 2019 16:02:17 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112EE1200F6; Mon, 9 Dec 2019 16:02:17 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id p5so996722qtq.12; Mon, 09 Dec 2019 16:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xS7RAVdtLcQNnHxtsOi4xzahhlQ6NCXM9VF03wrRj2E=; b=Uks7qrO5rGZnaBA70DEastIyQDHefoBkgcITQZGY5nwb+7Clx1pt2g4mdQtTkDb9ti 4/9NCK/DZFdCh7OwW3sepYLWCUIq6E0dL1fobsU2oItoPMrWgUf0HbQIha9uzwILm0Yt Wyujv7HlUd2xPlUkfXsMar3XotuIciOW1C/XIP64lLQOvNLeeZchWp0XhNlvFkojc0ic L0EkGw0UagxbzbG5T6YUZnTuhOK19sJrZgykSqBNoalKHR8toxcfZfPeI2Izhjsy+7uR FJfkFXemWy5oDe/jTLIrKqBWhkCenBLhHe+0SnMmuV9PGO/z8qfR1vAaJLKFtP0+SlkK Dvmw== 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=xS7RAVdtLcQNnHxtsOi4xzahhlQ6NCXM9VF03wrRj2E=; b=XyAHqsfPRILw1+qfmdz/VSJipUtdAdwnXKBnKIPYnUllFpVHX7gIBlC5o3pBmBV07W oEbEAUfYSXPRqy1UwvY3jr7pKZZZb/AOZc+ugRayEJAn4We38Rky9sznXH0e0M3OZhq4 08rrCgdUqMjEyRpO0BFzOM3njv6aJaqkx57cKtfQSZAM6ionIoxtaWU8IFi7kftBUU2l onkmw6/EfQWmOa9/+Q+i+nFs5SRDDVzzDa2zgWbUTIuTWFgBVaRsCaxstt/E/Lvk5UMV RDeBCIg8xGQwUFVXb9Lpfd8R7/+6eQyeDdt9T694r5J5bvpc3L4hGuQvXrWhWI3PX4IX Ao6Q== X-Gm-Message-State: APjAAAWeCdqQjoSeXPhkMb71YRSvvVGYEqGnk371uv5kP9pVQLPRxJCG 8Xevc6pEAdtqW8pBOTnURuCT2d1ASm5j/W2OB1bfWA2j X-Google-Smtp-Source: APXvYqyxtU933tI79UQP3jKc64xNSfKoCeLt2WYfajaLdiAO8WuheWet+Lt2zi89vubnUYf0lmJAqScZRFYnp1ziAcA= X-Received: by 2002:ac8:6f75:: with SMTP id u21mr28224775qtv.52.1575936135646; Mon, 09 Dec 2019 16:02:15 -0800 (PST) MIME-Version: 1.0 References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> In-Reply-To: From: Jen Linkova Date: Tue, 10 Dec 2019 11:02:04 +1100 Message-ID: To: dhcwg@ietf.org Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:02:19 -0000 Hello, Thanks to everyone for very productive centi-thread on draft-link-dhc-v6only-00 ;) Here is the improved version, -01. The main changes: - The option is not zero length anymore. It has 4-bytes value which might contain V6ONLY_WAIT timer. Benefits: --- allows the network administrators to pilot the changes and rollback quickly if needed; --- addressed some concern about an option having zero length (allegedly it might confuse some clients) - Using a dedicated address to return to clients is now an optional optimisation. By default the server is expected just to return a random address (as usual). - Typos fixed (probably some new typos added though). The authors would like the DHC WG to consider adopting this document. Thank you! ---------- Forwarded message --------- From: Date: Tue, Dec 10, 2019 at 10:44 AM Subject: New Version Notification for draft-link-dhc-v6only-01.txt To: Tomek Mrugalski , Lorenzo Colitti , Jen Linkova , Michael C. Richardson A new version of I-D, draft-link-dhc-v6only-01.txt has been successfully submitted by Jen Linkova and posted to the IETF repository. Name: draft-link-dhc-v6only Revision: 01 Title: IPv6-Only-Preferred Option for DHCP Document date: 2019-12-09 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only Diff: https://www.ietf.org/rfcdiff?url2=draft-link-dhc-v6only-01 Abstract: This document specifies a DHCP option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- SY, Jen Linkova aka Furry From nobody Mon Dec 9 16:05:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233C31207FC; Mon, 9 Dec 2019 16:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01yc9Sotes_l; Mon, 9 Dec 2019 16:05:47 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 92BCE12021C; Mon, 9 Dec 2019 16:05:46 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id c19so17676327lji.11; Mon, 09 Dec 2019 16:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=J2HZ3aMRMXomZ/toT+ZhR04uNpZ4M/SPNBlYP6iSqOQ=; b=cmpYeAIJaSiVRKp0h+p3Rq1chCBzfKm32YtOeJtFteqkFEF+Zc6r2h48eRXb10TAFy twqPdIgETyD8MGo0Y+1hBOlekZp4thxdTTko3ux6KHFrwy4TBSR6nHu5HcmRqxF5dmQx Q2421JagV0DlCiZXjMpbg9Dt8ESKjd0e6wxDwCg2LqO9FVS0fqlfA/Fabglngc6ZhE16 RtFklyaCvcmp5fyCpKpP/cov1O6WX5MvuPvlgYe7mnZyECW8IyCBJT6skL1bdXRiBK6U d74sahVDxUWOGxrXizdEwMmyrB10LB9X+0f4IZNCauMFU16IjN0I7V6Kacoh8Wfzx8FU V3sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=J2HZ3aMRMXomZ/toT+ZhR04uNpZ4M/SPNBlYP6iSqOQ=; b=ORCYkfEG8BT5apXv7cUc3glh2HKuGfyomXzVx5gg4+DWq3XgZVcKRba9sazVSFAlKJ cioqGnk+M4VPQOEqhgZA1mF5LL0wCt4I+f64RheuFdHCQhEmMCco7XAqrh0ERQMnOntl FDARU71SzIAtEPsGlItcQAhpRoVukwp/cJ8fW3t8o08H4d/trje0XVdg8mjnj+lA4Siv jjcQhsGUkyMqHSj1UwatgS8MUcyEJJdCAksiB8j0mwoYF8URhvifQKWmV5Z6xDNrKJJM VrVuxEGxttisLhP3/kVDSeF5t+tTJIiCsYLwFtOnzrHBrRcHMH52z9rFyyALOUynYjuw LOjQ== X-Gm-Message-State: APjAAAU81lay6Fd2yL3trx+DLoBanfsaFZOUH2fy/cI0bNzLF8nlZpvA fLRsLUeA7pw8Esbh79gxf1gk3n6jA682og== X-Google-Smtp-Source: APXvYqzD/mamozp74acVAkrcX3radUQDPgWugEneEhaCq/QCzV6afPerLATtgSUN94EfSkaoKHMyqg== X-Received: by 2002:a2e:2201:: with SMTP id i1mr17862361lji.110.1575936344196; Mon, 09 Dec 2019 16:05:44 -0800 (PST) Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.gmail.com with ESMTPSA id b10sm435624lfj.71.2019.12.09.16.05.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 16:05:43 -0800 (PST) To: Lorenzo Colitti , Jen Linkova Cc: David Farmer , Michael Richardson , dhcwg@ietf.org, V6 Ops List , draft-link-dhc-v6only@ietf.org References: <28594.1575483729@localhost> From: Tomek Mrugalski Message-ID: Date: Tue, 10 Dec 2019 01:05:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E4131C4B956A3CD8E4984E4" Content-Language: en-US Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:05:48 -0000 This is a multi-part message in MIME format. --------------8E4131C4B956A3CD8E4984E4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06.12.2019 08:21, Lorenzo Colitti wrote: > On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova > wrote: > > "If the pool is explicitly configured with a dedicated IPv4 >    address to be returned to IPv6-only capable clients the server MUST >    specify that address as the client's network address and MUST NOT >    verify its uniqueness. > > > That seems difficult to implement on the server. Why not just return a > normal OFFER from the pool? That way, if something unexpected happens > and the client sends a DHCPREQUEST for it, the server can hand it out > as normal. > > The alternative is risky. If the server uses a bogus OFFER value, and > some client requests it and the server hands it out, that creates the > possibility for misconfiguration or bugs to create really bad outcomes > where multiple hosts have the same IP address, or some things on the > network (e.g., snooping switches) think that multiple hosts have the > same IP address. +Tomek Mrugalski >  any thoughts on whether this can > be implemented easily and reliably on the server side? I would go with a normal OFFER from the pool. Some servers (such as Kea) don't reserve the address at all when sending back OFFERS. This seems like the most robust approach. Clients that correctly implement the draft would never send a REQUEST for addresses offered. Buggy clients that implement the draft in a broken way and request the address, would simply get the address and the server will continue offering other addresses to IPv6-only Preferred capable clients. In Kea, sending an address from a pool would work out of the box and not a single address would be allocated for ipv6-only preferred clients. The alternative (bogus address or small pool of just one address) is much more tricky to set up and there may be messy corner cases. Every DHCP server I know does various checks if the address belongs to a pool (so setting something completely out of the range could break down various mechanisms), it could mess up statistics and thresholds. The fundamental role every DHCP server is supposed to play is to ensure that the addresses are not duplicated and there are many mechanisms to help ensure that. If we decided to go with bogus address shared by all ipv6-only preferred clients, most (all?) of such mechanisms would have to be conditionally disabled. Let's not do that. Tomek --------------8E4131C4B956A3CD8E4984E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 06.12.2019 08:21, Lorenzo Colitti wrote:
On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova <furry13@gmail.com> wrote:
"If the pool is explicitly configured with a dedicated IPv4
   address to be returned to IPv6-only capable clients the server MUST
   specify that address as the client's network address and MUST NOT
   verify its uniqueness.

That seems difficult to implement on the server. Why not just return a normal OFFER from the pool? That way, if something unexpected happens and the client sends a DHCPREQUEST for it, the server can hand it out as normal.

The alternative is risky. If the server uses a bogus OFFER value, and some client requests it and the server hands it out, that creates the possibility for misconfiguration or bugs to create really bad outcomes where multiple hosts have the same IP address, or some things on the network (e.g., snooping switches) think that multiple hosts have the same IP address. +Tomek Mrugalski any thoughts on whether this can be implemented easily and reliably on the server side?

I would go with a normal OFFER from the pool. Some servers (such as Kea) don't reserve the address at all when sending back OFFERS. This seems like the most robust approach. Clients that correctly implement the draft would never send a REQUEST for addresses offered. Buggy clients that implement the draft in a broken way and request the address, would simply get the address and the server will continue offering other addresses to IPv6-only Preferred capable clients. In Kea, sending an address from a pool would work out of the box and not a single address would be allocated for ipv6-only preferred clients.

The alternative (bogus address or small pool of just one address) is much more tricky to set up and there may be messy corner cases. Every DHCP server I know does various checks if the address belongs to a pool (so setting something completely out of the range could break down various mechanisms), it could mess up statistics and thresholds. The fundamental role every DHCP server is supposed to play is to ensure that the addresses are not duplicated and there are many mechanisms to help ensure that. If we decided to go with bogus address shared by all ipv6-only preferred clients, most (all?) of such mechanisms would have to be conditionally disabled. Let's not do that.

Tomek

--------------8E4131C4B956A3CD8E4984E4-- From nobody Mon Dec 9 16:17:41 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE17120810 for ; Mon, 9 Dec 2019 16:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 EN-XeIRkOYNU for ; Mon, 9 Dec 2019 16:17:38 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DE112021C for ; Mon, 9 Dec 2019 16:17:38 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id k20so6500099pls.3 for ; Mon, 09 Dec 2019 16:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rkB8WEdbNDLZ1YUkeHtzEK4VxhcBloZevEQ1jCmKJOo=; b=P8gw4BBBhCxdXySDRwIS3HPRdm5yYCfHl0M53V7c2xxCN0yNG66oF1LJizwvO0JT+c SbTkRNGvNThE1qrc2ZpO9PvGpredFaphe0cpYFGJeyHDWka4t2Vko0/USDRMId1WjUho JVu1jhE48NxRpaa3Im3QpM/TvXsTtBuqn//T9IQXhc/9KgK00whsinZ0VhO2yY2xwZGW 8YZOQYU2S8prJpPDGUOCwKm6szk/5DDvW3vXKl3Qd7OMCjAjHdKH39RjcKTc+xVybGvE ykynQrnSsITYM6Sr3H66dRoHqfVPJEyK+migLP/hq9ruBqMHOWWO0zNGoH1w4b5TeClO Nj8A== 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=rkB8WEdbNDLZ1YUkeHtzEK4VxhcBloZevEQ1jCmKJOo=; b=Y6aZY8YCKVkDw/FsVqmdDjmWXYtQtaqLscSOke/flPmWgjORd/Ofsz+qbiq9JzSnZa I0NnU0Zw7pMoc+IuQbsRwG+HM6eFw9FzgoXysgvXx1TWLgMchvu6Q4VmlnqzY4xFx89/ xWKUfvj/E1S/ms9lV/ml6rSwM41Brea20CZdZWw7nacXfK6yLFeNfdUrWTRWMeAyxLlm KlCdpAWUp5gI79OGZU5lmidnk0IxLPMzVy3mc2oDX2PQqSurjtflj9UfNsBW6LMofkqz V0O/Xk4NcWesb65Qks1eg6vBwUxyzt+BzDTk0uUVP8wF55RWRcIbQDfX6mPFl/8XomNF s/7Q== X-Gm-Message-State: APjAAAXXNQ/wYDKx91yBvuI9YQdrH6E6j4uZJoLuVntp3dZMDNjQwfv8 oaGU/6ZXMoUbWuX5zEILE8PMYw== X-Google-Smtp-Source: APXvYqyycvwnJA+Go4Eg+0jlW8ajbHJZCyuQXl2J7WZN6ZgTVHj81Dhhhv3MKvTq3XpIV1i6x4jMIg== X-Received: by 2002:a17:902:8ec8:: with SMTP id x8mr30800011plo.119.1575937057664; Mon, 09 Dec 2019 16:17:37 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id e4sm606096pfj.125.2019.12.09.16.17.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 16:17:36 -0800 (PST) From: Ted Lemon Message-Id: <0EC7EB9D-1349-4F9C-BD13-A5A85719F5E2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE9B261A-C677-47E6-AC81-0E895A7D0257" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 16:17:35 -0800 In-Reply-To: Cc: Lorenzo Colitti , Jen Linkova , V6 Ops List , draft-link-dhc-v6only@ietf.org, dhcwg@ietf.org, Michael Richardson To: Tomek Mrugalski References: <28594.1575483729@localhost> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:17:40 -0000 --Apple-Mail=_AE9B261A-C677-47E6-AC81-0E895A7D0257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 9, 2019, at 4:05 PM, Tomek Mrugalski = wrote: > The alternative (bogus address or small pool of just one address) is = much more tricky to set up and there may be messy corner cases. Every = DHCP server I know does various checks if the address belongs to a pool = (so setting something completely out of the range could break down = various mechanisms), it could mess up statistics and thresholds. The = fundamental role every DHCP server is supposed to play is to ensure that = the addresses are not duplicated and there are many mechanisms to help = ensure that. If we decided to go with bogus address shared by all = ipv6-only preferred clients, most (all?) of such mechanisms would have = to be conditionally disabled. Let's not do that. It=E2=80=99s hard to imagine how this could be possible. You allocate = the address, then verify that it=E2=80=99s okay to send? That=E2=80=99s = backwards. I would expect you to allocate an address that is available = and valid to send. Otherwise you=E2=80=99d have to re-run the = allocation algorithm multiple times until you come up with an address = that works. So in fact I think that the allocation algorithm in this = case would just be a no-op, and that would not require a lot of extra = fuss. --Apple-Mail=_AE9B261A-C677-47E6-AC81-0E895A7D0257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 9, 2019, at 4:05 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
The alternative (bogus address or small pool of just one = address) is much more tricky to set up and there may be messy corner = cases. Every DHCP server I know does various checks if the address = belongs to a pool (so setting something completely out of the range = could break down various mechanisms), it could mess up statistics and = thresholds. The fundamental role every DHCP server is supposed to play = is to ensure that the addresses are not duplicated and there are many = mechanisms to help ensure that. If we decided to go with bogus address = shared by all ipv6-only preferred clients, most (all?) of such = mechanisms would have to be conditionally disabled. Let's not do = that.

It=E2=80= =99s hard to imagine how this could be possible.   You allocate the = address, then verify that it=E2=80=99s okay to send?   That=E2=80=99s= backwards.  I would expect you to allocate an address that is = available and valid to send.  Otherwise you=E2=80=99d have to = re-run the allocation algorithm multiple times until you come up with an = address that works.  So in fact I think that the allocation = algorithm in this case would just be a no-op, and that would not require = a lot of extra fuss.

= --Apple-Mail=_AE9B261A-C677-47E6-AC81-0E895A7D0257-- From nobody Mon Dec 9 16:35:11 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECEB120810; Mon, 9 Dec 2019 16:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwU2ciY1TeB7; Mon, 9 Dec 2019 16:35:07 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 1A54F120020; Mon, 9 Dec 2019 16:35:07 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id d20so17758273ljc.12; Mon, 09 Dec 2019 16:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MC500x2BUnfihAkUcsGLlwzAz+LZjMwAJ4QgMovNuaw=; b=Fc6zLEUjJirN/ixqXNCpXQZ9o85V4s7SE6h2rUX7d79iIJWC2VjI3qKqdfc8fErd7h uQf9fGSY9q+68rGuV8lePChMDX2EXCwsJu5hyMna1wkXStGMbVHVJSXab7+UT7ocjrS5 d8Uts/enp286LPvKon6QTqSTvwqPdNCVUwH626LqsLwk51tIsKLqgWVUhHGDa2ugH+vT QAgKoqG4fgdwX5hWA09YynZtLMAkI2SsPkShrprojQ+lShyiW8ZGDY5eiK4LjzklIav5 +6+jzgDqX5Qa5fjT6GtEYxoDYi5gyVYQvrwlfKi6CyCHQ5/CyLvu2vYp6pzy8ztiw6QY z2mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=MC500x2BUnfihAkUcsGLlwzAz+LZjMwAJ4QgMovNuaw=; b=A39DcPuXFNBzrH+YlhgsPYaxhznIIYO+hg2S4K+15mo9RAVt4YbxSI5ouwfs/+jbjZ 8xcQ8boCJfxuF5CAUcxNvCCOnt1Q/lI/I+Weu6saS0KaccD6ReUkQVqxaabQs2TQOWGN FUB86QkO0SHLMNHBnbMV/0ngLmvTT/r3xt+JeK/eo8yVtw8A3inImk1nQ7DLmH6IaDS4 thEb/ehRvdKM6ZDYvMFUAmlj30QonbYxa1qHhEu8+0O4wxq5ZBB5RJOoClUV8L+5xle+ dnmTjJz0kOYEOYHwub2FZhugH4ca1SM2auxyKEcNnqYfHQsW1Kx5ukXV5+Tdum12S2ml 3+dQ== X-Gm-Message-State: APjAAAXgCPYBEfmQYqTbT1Gi6rctSBmyl4V8iXGNStKh/sknlQzWkSmY 7k20OHfEiZkoEhJpXNK9aHHW+fNIpcwgkw== X-Google-Smtp-Source: APXvYqwqTBhGFYZqnU6bjS/P44Q6dsd4jqTnxdQtL0PEN/3akPoxne28Tnt1kUBYI1TShvxp62vTTw== X-Received: by 2002:a05:651c:285:: with SMTP id b5mr18669449ljo.14.1575938105031; Mon, 09 Dec 2019 16:35:05 -0800 (PST) Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.gmail.com with ESMTPSA id m24sm855081ljb.81.2019.12.09.16.35.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 16:35:04 -0800 (PST) To: "Bernie Volz (volz)" , Ted Lemon , Jen Linkova Cc: "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" References: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> From: Tomek Mrugalski Message-ID: <45763b7f-1d76-78b0-5d7f-6469b25a007c@gmail.com> Date: Tue, 10 Dec 2019 01:35:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:35:09 -0000 On 04.12.2019 19:36, Bernie Volz (volz) wrote: > A minor note about the draft requesting use of (DHCPv4) option code 108. Per RFC3679 this was in use as a "swap path" option at some point, though never published as a draft. That is why it is marked as "REMOVED/unassigned" as the idea was to NOT reuse these option numbers until there was a need (i.e., no other just "unassigned" option codes were available). While I have no objection if the draft wishes to request use of that option code, I just wanted to point out that there could be some other conflicting usage out in the wild. As a person who put that text there, let me explain my reasons. RFC2132 (Mar 1997) said that option codes 128-255 were reserved for site-specific options. RFC3942 (Nov 2004) reclassified 128-223 as a general purpose option codes under IANA governance. However, any implementation created between 1997 and 2004 could have used those option codes for whatever purpose they desired. It's been quite a long time ago, but we all know about long tails. With that in mind, I tried to find the lowest option code that's available. I was not able to find any specific information about prior use of codes 102-107, except RFC3679 saying they were returned (and thus previously used by someone). Code 108 seems safer than other codes - it is below 128, RFC3679 explicitly says that there was an idea to use it for swap path, but that must have died quickly if no I-D was ever published about it. So it seems like a safe bet. At the end of the day, this is only a request for IANA. If this gets published, they may honor or ignore it. Tomek p.s. Apologies for sending it today. Museums are supposed to be closed on Mondays. From nobody Mon Dec 9 16:51:09 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69425120020 for ; Mon, 9 Dec 2019 16:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FfMM0gy8O3Hv for ; Mon, 9 Dec 2019 16:51:03 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D0F12021C for ; Mon, 9 Dec 2019 16:51:03 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id s64so1271807pgb.9 for ; Mon, 09 Dec 2019 16:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JMzt8bcGe66R/DxP/K6hkq7xN7vDaYeEQrcAocN4HCk=; b=qgiCN2Zmth/hTDc6GAM64PY8bntDg3922EJLtNjFgJWM0uluLcwZcl1/z5ml4GH3GU Rvw3uLR3rJDVevmOrv6bXlZH9QAPaga03QRHTyb3y0krgRWsu6VxiQKcaGsYEToUi16O N5cFj5CwhZGITLjvJl7d9yAvuccEK4mYphQ+nAbWjNaWu1cr3aAJpLfOzegYfTVIwf5S OnInchh2ao4XEBw0ZwjSscrfyUsk3xph4bPAl3hwkGgjpkb9BZszoBIxoRZyeRKUew5V 7Dhb/36Y6xhhIkh3/eaP6XiOttfYObnySIY+oH37A0JbZ4eqozLRSCF9LGFzHK9Vrsvj 1Jmw== 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=JMzt8bcGe66R/DxP/K6hkq7xN7vDaYeEQrcAocN4HCk=; b=MPGOJLlV5IHK/tXkzvOa/4MeBtDkGMp9dRl0jhpdSh35nArA1M9tBdCChDM5ngZ+fK DmtBGLs6QPIYW45GxsWYfo+R0d56v+mjyPDr1iDOKgUKp6VyNhjUkgX31IRsqI5tligG voK7Po5i3WsE00dbvc9kS7bEbxvfYHIhb8+MHhyv8DdWfVKgoW04KKFDgK6QBm1wdpV3 Q4dr0ZWMsoP5WGlH/VahnB/GjnZqx+TNDty1rGt6yOFQhPJ4u+8PhoJm8Obp74zG4hr/ ym1BAGZ+Oscp6+7kB9xg7BORzoNaIc9VWGDET19t1r96luN4hA62jcr0AqKTWoF16Qqt MHYQ== X-Gm-Message-State: APjAAAXO8flt2lK5rES4aT9Runf1ndIZVWy15Hzf4MUESDXiTwnbNAoG wgP4gGLBFHCt3wL4Ecc8UdxQNQ== X-Google-Smtp-Source: APXvYqzOESRnvzy1gHfMXvrfw9MoNTF+RoZQy9/e4w1rJM909mwRZTqJCflB8OinR628u2o95lzlZQ== X-Received: by 2002:a63:213:: with SMTP id 19mr2605880pgc.160.1575939063229; Mon, 09 Dec 2019 16:51:03 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.138.54]) by smtp.gmail.com with ESMTPSA id c1sm656804pfa.51.2019.12.09.16.51.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2019 16:51:01 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB7A0532-746A-4680-BB7F-6EECF9FCD8BB" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Mon, 9 Dec 2019 16:51:00 -0800 In-Reply-To: <45763b7f-1d76-78b0-5d7f-6469b25a007c@gmail.com> Cc: "Bernie Volz (volz)" , Jen Linkova , "dhcwg@ietf.org" , V6 Ops List , "draft-link-dhc-v6only@ietf.org" To: Tomek Mrugalski References: <32A5E9AF-60E8-413D-B724-400363F32B09@fugue.com> <45763b7f-1d76-78b0-5d7f-6469b25a007c@gmail.com> X-Mailer: Apple Mail (2.3600) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:51:07 -0000 --Apple-Mail=_DB7A0532-746A-4680-BB7F-6EECF9FCD8BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 9, 2019, at 4:35 PM, Tomek Mrugalski = wrote: > With that in mind, I tried to find the lowest option code that's > available. I was not able to find any specific information about prior > use of codes 102-107, except RFC3679 saying they were returned (and = thus > previously used by someone). Code 108 seems safer than other codes - = it > is below 128, RFC3679 explicitly says that there was an idea to use it > for swap path, but that must have died quickly if no I-D was ever > published about it. So it seems like a safe bet. I tend to agree. --Apple-Mail=_DB7A0532-746A-4680-BB7F-6EECF9FCD8BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 9, 2019, at 4:35 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote:
With that in mind, I tried to find the lowest option code = that's
available. I = was not able to find any specific information about prior
use of codes = 102-107, except RFC3679 saying they were returned (and thus
previously = used by someone). Code 108 seems safer than other codes - it
is below 128, = RFC3679 explicitly says that there was an idea to use it
for swap = path, but that must have died quickly if no I-D was ever
published = about it. So it seems like a safe = bet.

I = tend to agree.

= --Apple-Mail=_DB7A0532-746A-4680-BB7F-6EECF9FCD8BB-- From nobody Mon Dec 9 16:54:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416181200FE for ; Mon, 9 Dec 2019 16:54:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jphBS1iWaU59 for ; Mon, 9 Dec 2019 16:54:43 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F44912002F for ; Mon, 9 Dec 2019 16:54:43 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id k6so14990858qki.5 for ; Mon, 09 Dec 2019 16:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6s0barDFevLB4YVSAA05YLLj3Bf8xYVxqwlpG6QyOy8=; b=lPZU6xZeAfX4p3renSxIHBuhN6Zjm7O65ACohVSxyTejfREfQaKlyfM/kSNCmPE8AU mVQpBgHCvMSS0vzgeICrc6XlSqyKL6KC2x/mccAyRvJYQsQRWOiUpCRyOTX3+HJQw3/p DVjmkmUM6mLdas04EPkeTKLciQVOW6uzDWjQ7psQKy2oEwvEggNiIxEaaYe4ayASx+UV 6mcIkMqYE0mnvwnf6UovIdpuJm3DHXOEryXdXsBcKjOmFItW8TTkLeKQBPZAR6chhNcb wdTJs5OkqkGNcQqYBXbOZsZEpxTt8KMpgkPO0UhgcornZIy6vBKoDotfQ0Mo9LmUGBYs AgKw== 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=6s0barDFevLB4YVSAA05YLLj3Bf8xYVxqwlpG6QyOy8=; b=n+oma0eH4jxutg2nLqhFpqfru9hhYWTlOvqJ+rtv3bQQRkkcq2Sl7XFhrSWi7IXV6+ DdW+LYgSm6XCr0SD2NXJiKZVqE5S84XKmpOZiHp/jBZS87Y2EffQu1CXmDTBpZBHjHYR /4B6T4HSbeUAlMKGSDdZ2gqBW6G2OWzZOj45DEdgVyiw6kKpvpCATvLgwWPnTOYpxYg8 q7Odmj648y6eGNdBJFibpefDhqY3PepOyMk4177iQN9FhWCjGsNd/7z80tQGR9dzoU4X p0P6e6QGbN86C9ok+HzMUHH3saIA6iCckPCSjWyfP2Mfi0vgJ/o3Vqg9cE8RPOYtNyjS nODw== X-Gm-Message-State: APjAAAVThLkCwwex3aKhPZtTfSkPW1eRlZ+1Z/M+KqXD8l3UnrTcbsj/ Ab6GOp/Od5OkkPZelo+1ujrBavJFCr9Z6TD+rEPDzg== X-Google-Smtp-Source: APXvYqx6IchNcW5BsNDyj9XwuF62J++WG9scV61BuAxvSux/XjUAylITgqA3hkJqcnS3HBZI3t3Qg47b7Mt2ho04txQ= X-Received: by 2002:a37:9fce:: with SMTP id i197mr1755737qke.466.1575939282033; Mon, 09 Dec 2019 16:54:42 -0800 (PST) MIME-Version: 1.0 References: <28594.1575483729@localhost> <7ac18a46-31d9-74cc-117a-0fd908413aac@gmail.com> In-Reply-To: From: Jen Linkova Date: Tue, 10 Dec 2019 11:54:28 +1100 Message-ID: To: Philip Homburg Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 00:54:44 -0000 On Fri, Dec 6, 2019 at 9:04 PM Philip Homburg wrote: > One thing that worries me a bit is that with this option the host signals that > it doesn't need an IPv4 address if there is NAT64. > > There are two things that can go wrong: the network provides the NAT64 > transation prefix in a way that the host doesn't understand. I do not think the network is expected to provide NAT64 prefix now in any way. Our pref64 draft has not been published yet, and anyway it's an additional signal. > The second thing, what if some other IPv4aaS technology becomes popular, > do we need a new option for every IPv4aaS technology? Ah, that's the unresolved issue in the draft yet, some more work (and input from the WG) required. What could be done here: 1) we can declare that we do not believe there is any chance of any other transition mechanism for IPv6-only hosts to appear any time soon. 2) we can - as it's been proposed - add a field to encode the transition technologies supported by the host (e.g. as a bit mask). Personally I'd be very surprised to see any new mechanism to be developed and adopted but I'd not oppose #2 either. -- SY, Jen Linkova aka Furry From nobody Mon Dec 9 17:14:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1932112002F; Mon, 9 Dec 2019 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47HhJxUdo-1x; Mon, 9 Dec 2019 17:14:49 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3C7120020; Mon, 9 Dec 2019 17:14:49 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id v201so12243051lfa.11; Mon, 09 Dec 2019 17:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aNUfNL523SAAHsNe0oA+mh9yUEz1g9S8mN3eqWKwHMQ=; b=PEGiT8kXfEbWgmw0txxgLJtqkKCzD3pg207dpe9zIT0GcOQCUz9Dn2SjDZ5XdUpy0z ZKDh5vgzwDBuXSYw9v3bRpluxtjPrGULFWfVa1N0w5moUqMu8bWafGyEE4EcpmN5AxFJ D4SKgYzg8tTVbCWQJZO4jkE9caC2AvaOjXcOl93mj899mmwgU+cg+hYa0oQoK5Avjkx0 PN03Ci6e6Xnheq1MjPnWWwGNvGTr/eGfysSl3iCXNFioeX9FlV4O4pde/6hgiS+lRJ6T bhUlEplD3GuNsc0FAFWl6anukizVqyenhtATLzHLXsBUAd1mUOrj2ZzyU4XmfwlrUruv kWmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aNUfNL523SAAHsNe0oA+mh9yUEz1g9S8mN3eqWKwHMQ=; b=ZHjdSBkQbpZEXEcNvzIfbLMW0c9FCakAjSyit/kx0BF+GbDJIZCNo0SA5ajoHM16Vp 3FGjCfZ6xmT7jP277x6fBvR5kcCRRKURXnmgMJMZW+Na1Q/ZF8GcESiJqiZxHA5nR2jF 5wfQXP/5i+wYbpT/giQpSr5XZwTADpFHmYUJG0lciiG3RFIIIfLJfMRPhfewcsZhVnUl 8o+et+fnYzWb++REd2DxrI52xa+FQ2/oLRb8Hecy++hY+iT85srqpwI+UAFPgwV0ymw2 bJMHANjyDrmBegnMc7I+Hf3OP7FXiVLttuqPxagrH+STUFT2O30AbT3efuJ8ZWR2U4pD Nhiw== X-Gm-Message-State: APjAAAVJEO+Un9sIRiRydqO/c0+Tr9wgBTYB03WPTUiC+5amKG2yEZEB Wf/yLBhJj47/Ho5yRDs+tv6EmdahlpMv5Q== X-Google-Smtp-Source: APXvYqyzNqfTDKOR/jhnwstaoPxrKWkCDsO+xF+XQbCCfYV35zYQ8QF2xEaDvA4Smv+im1AM71BH2Q== X-Received: by 2002:ac2:4476:: with SMTP id y22mr17368602lfl.169.1575940487371; Mon, 09 Dec 2019 17:14:47 -0800 (PST) Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.gmail.com with ESMTPSA id i5sm766824ljj.29.2019.12.09.17.14.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 17:14:46 -0800 (PST) To: Lorenzo Colitti , Roy Marples Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> From: Tomek Mrugalski Message-ID: Date: Tue, 10 Dec 2019 02:14:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 01:14:51 -0000 On 05.12.2019 04:48, Lorenzo Colitti wrote: > Additionally, I would expect that a separate option would be simpler to implement on the server side. This is because the server can just continue to consider the lease time a property of the address pool, and treat this new option simply as a statically-configured option that is returned to clients iff they requested it in the PRL. If we use the same field for the lease timer and the V6ONLY_WAIT timer, then the server will need to change the lease timer in DHCPOFFER packets depending on whether the option was requested or not, and I would expect that to be more complex. +Tomek Mrugalski any thoughts on this? >From the server perspective, a new option is much simpler. There's no question about it. Every DHCP server I know has the ability to define custom options, so deploying this should be a simple configuration change, no code change. Most servers offer reach policy mechanisms to govern sending options back that can be used to fine tune sending the option back (blacklist specific devices, list clients by MAC/client-id/whatever, do client classifications, etc.). In the DHCP protocol, most burden of tracking various timers is on the client side. Server really needs to track lease expiration since there's no lease being assigned, there's no state to maintain here on the server side.(Ok, it's a bit of oversimplification.) This should scale really well. Tomek From nobody Mon Dec 9 17:25:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A5512002F; Mon, 9 Dec 2019 17:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6ZijcW-R4qB; Mon, 9 Dec 2019 17:25:12 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86533120020; Mon, 9 Dec 2019 17:25:12 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id n12so12307282lfe.3; Mon, 09 Dec 2019 17:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4j2ZzxUwW8ccA7KFsVVKICg1o+x1H/1VxfohGIeBxm4=; b=TxrpdVbFhOEEP6ubOX0SIe1nSGYz8jPT2T6N2sG45uXxF1w7ucmfkkqNEtyW/gI2iL 2+MNL3ZZgj1UGHMi8mAY0HvxDH9w0b53A7Dd/ZnH0hHul/kCCSRcnmmrwMmJGfxv+cqw Y8aqhuDcI8o6XacUl/Uuhk+HRCR4RzDtODeLG+CWz3IpzEHGVvOojGQs/lkWvm82Hb8j 2zBuwP3YnKUrEc8WsTPJsUrQYgQxtm1YusfMibIIGRvxHyv7vVNfO6gHj+JGjmo5p6R/ xElsoklOJHwPuv9yFf2snBv29AysLbsoVtRztawj09or8jilK9qCMeC3O6Jp6JygeAgv ReQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4j2ZzxUwW8ccA7KFsVVKICg1o+x1H/1VxfohGIeBxm4=; b=nWbj5m4JJb8GLmXQ6vuXstb5UBhvxU0pZkRH/4bIRqgv6vd0KH8hHasxhfxNg80SLE qtdnQR54GvqQicAMTtnrQ+5uGj9RkKuZnbEyuoAN3I7d5Fm8vnlpeB+6QisFqSXaF/IW nXbguSMPVnVoLM6NxEyimNlMP9kUF3hoABWq9y0+pnAwrEHX5G0BjEaloDt+2SLtEjV7 +g5vrLi1yS7UWAxMk6C1bvIL9TD7MkB/R3ihGKNnDPzO3jPRvjWAyg9jL7UCOhynM4aw HcRbsXft4A4n+EBKzngRrWSs6lkQxcakmOADWW3tmZj05xR1sjaFWEAp50is3dyZC5eZ Tu4w== X-Gm-Message-State: APjAAAXMlbsJPF5n5TqcOvjDMzl2Ju3Mc0nfMAvJYuI2Y4Ddaui8yDqb u0aiEr2CVRF0MeRub2OC7QSa9Ui0YNRBWw== X-Google-Smtp-Source: APXvYqwp7bZ1CH08pcvTWM+6WgZIujGxQv8Thkezt6LUqo3/X4a/EvR2ffWFmFOo9JVvz3Mk1w9BPA== X-Received: by 2002:a19:ac43:: with SMTP id r3mr17349614lfc.156.1575941110471; Mon, 09 Dec 2019 17:25:10 -0800 (PST) Received: from ?IPv6:2001:470:6111::5d1? ([2001:470:6111::5d1]) by smtp.gmail.com with ESMTPSA id y29sm746158ljd.88.2019.12.09.17.25.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2019 17:25:09 -0800 (PST) To: Roy Marples , Lorenzo Colitti Cc: Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> From: Tomek Mrugalski Message-ID: Date: Tue, 10 Dec 2019 02:25:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 01:25:15 -0000 On 05.12.2019 05:45, Roy Marples wrote: > On 05/12/2019 03:48, Lorenzo Colitti wrote: >> On Thu, Dec 5, 2019 at 11:50 AM Roy Marples > wrote: >> >>      > The T2 timer is about the validity of the address that is offered >> >>     Wrong. >>     The T2 timer addresses the lease as a whole. At this point the address >>     is just meta data, just like domain or dns servers. >> >> >> Regardless: the T2 timer is about the validity of the information that is offered. The V6ONLY_WAIT timer is different: it's about when the client should ask again if the client *does not request* the offer. > > So in simple terms. > The server offers some information. > Given this information (in current DHCP semantics) we can RENEW (T1) or REBIND (T2). > If the client does not request the offer (hey! I see this new fangled option here that says NO DHCP) the client can still accept the T2 timer at the very least. > > Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new timers. That's a good analogy. Would it be helpful if the V6ONLY_WAIT description was update to say something similar to: "Upon reception of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"? The effect would be mostly the same, with two changes: 1. technically it would not introduce a new timer 2. it would most likely require update of RFC2131 I don't particularly like that approach, but could live with that if that's what the consensus is. >>     Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP >>     should not depend on any IPv6 settings - or vice versa. Is it too much >>     to ask to keep protocol setup separate? Perhaps it's poorly named, but it's very much DHCPv4 option. The option is not supposed to affect any IPv6 behavior. How about calling it what it really is: DISABLEV4? Tomek From nobody Mon Dec 9 17:48:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F99912006B for ; Mon, 9 Dec 2019 17:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 tgoyB6CwLYIT for ; Mon, 9 Dec 2019 17:47:54 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A583212001A for ; Mon, 9 Dec 2019 17:47:54 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id s25so2352786iob.0 for ; Mon, 09 Dec 2019 17:47:54 -0800 (PST) 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=YtARK3iwEY4OoQFhXpw6xpyN04Lk1N7ayZOl00wAGBI=; b=RifKpaAD9C01VLg7GyMF2kRPsxKH6miL69npG7vWns74op0PF5Idyjdh78l5dAOYhl tcAZU3FSixbjMBQ1Ey6G0gFjeeCqL6/EristbC/0hYzQ9ktUWPYl0n4pEGRSWw21yEsa MWERv4Q7mDxEKcilPTDSKPgT65BvgmBKcyhPEi0jePjvS94UVj3Niauw8Ru3aeNtergG SRZ0ViJPRDytT/3SWGCg/V4TYIU+zi4yX3/jXcJtKAkBGVaEh6/tyT/H91I2glYawhFq 6kUEE8lVA+Y+yNlJH33ZUGi5cWHrTqJS8g5x1Sm/O7O6WXNwwq/KdjZjs6yPAzDkhoRk aLkA== 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=YtARK3iwEY4OoQFhXpw6xpyN04Lk1N7ayZOl00wAGBI=; b=hBrTvyU1kBKGvO4OqsmoE1vPX5GZAU+BYqNwm4b/kTdgsFSR/Z0x/gUzGzoEkJt+GO VCwhgTA+e2PDaHk8GMEYl9sRyYLJVMVikdwKRohFCZZYRiYzU8wV42VPASX3I7Nf0tfK CFc/p5MmCvnWdSZWCjf5quOO+XM4Zv6qOltKmmSL0xXZrBvMNAvRjv7b/9SHPzy4ou8d Wa/OFgQ4mypCqgwro6j31mjyrY8zlvDeKdKuQ0oCe3vQvQzkmxE4UiIRQ9MgAdDCy93n RJ6vcPS7qYAyWjkk8SeHjUo3rqFtO26oV++dJVeuoFNncowPC4Q0M+NC5JidBJwt45kB KYCg== X-Gm-Message-State: APjAAAUXyVzE3vaYkiQYMO5lkaXCqZU6ZnvgV91SFJhGOWbhMa2SHsuA j0V0ElAqKkNTL8Z6NnE5hEfGaN3QLLP48mAs4wgRhg== X-Google-Smtp-Source: APXvYqy7x4LoHOjpv2zCze/fgIRZNMUiUzS85SbOK8cfe753wuFZMkIJ8N/XqVMXmy11pehwzMbOKzjLnXse2r7Ub1c= X-Received: by 2002:a05:6638:76c:: with SMTP id y12mr5574462jad.95.1575942473729; Mon, 09 Dec 2019 17:47:53 -0800 (PST) MIME-Version: 1.0 References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> In-Reply-To: From: Lorenzo Colitti Date: Tue, 10 Dec 2019 10:47:41 +0900 Message-ID: To: Tomek Mrugalski Cc: Roy Marples , Jen Linkova , dhcwg@ietf.org, draft-link-dhc-v6only@ietf.org, V6 Ops List Content-Type: multipart/alternative; boundary="00000000000055a08a05994fb3e3" Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 01:47:58 -0000 --00000000000055a08a05994fb3e3 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski wrote: > That's a good analogy. Would it be helpful if the V6ONLY_WAIT description > was update to say something similar to: "Upon reception of the V6ONLY_WAIT > option, the client sets its reverts back to DHCPDISCOVER retransmission and > sets its retransmission timer to V6ONLY_WAIT seconds"? If it sets its retransmission timer to V6ONLY_WAIT seconds, then if the first discover is dropped, will the second one be V6ONLY_WAIT seconds after that? That seems bad. Once the V6ONLY_WAIT timer fires, we want the retransmission interval to be back to a low value, like 1-2 seconds, right? Perhaps it's poorly named, but it's very much DHCPv4 option. The option is > not supposed to affect any IPv6 behavior. > > How about calling it what it really is: DISABLEV4? > It's not just "disable IPv4". It's "disable IPv4, because you there's this other thing instead". See https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w and follow-ups. --00000000000055a08a05994fb3e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2019 at 10:25 AM Tomek Mr= ugalski <tomasz.mrugalski@= gmail.com> wrote:
That's a good analogy. Would it be = helpful if the V6ONLY_WAIT description was update to say something similar = to: "Upon reception of the V6ONLY_WAIT option, the client sets its rev= erts back to DHCPDISCOVER retransmission and sets its retransmission timer = to V6ONLY_WAIT seconds"?

If it sets it= s retransmission timer to V6ONLY_WAIT seconds, then if the first discover i= s dropped, will the second one be=C2=A0V6ONLY_WAIT seconds after that? That= seems bad. Once the V6ONLY_WAIT timer fires, we want the retransmission in= terval to be back to a low value, like 1-2 seconds, right?

Perhaps it's poor= ly named, but it's very much DHCPv4 option. The option is not supposed = to affect any IPv6 behavior.

How about calling it what it really is: DISABLEV4?
It's not just "disable IPv4". It's "dis= able IPv4, because you there's this other thing instead". See=C2= =A0https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-B= p0EW0P7w and follow-ups.
--00000000000055a08a05994fb3e3-- From nobody Tue Dec 10 02:31:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD287120131; Tue, 10 Dec 2019 02:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykxwALr9SsKg; Tue, 10 Dec 2019 02:31:33 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D32120103; Tue, 10 Dec 2019 02:31:33 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 47XGZD08qFz1yYn; Tue, 10 Dec 2019 11:31:32 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 47XGZC6Hyfz8sYg; Tue, 10 Dec 2019 11:31:31 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6D.corporate.adroot.infra.ftgroup ([fe80::4c24:f1ba:2b1:e490%21]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 11:31:31 +0100 From: To: Jen Linkova , "dhcwg@ietf.org" CC: V6 Ops List Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVru0bIVoqZT4HA0q2weq1kQt5xaezDOyQ Date: Tue, 10 Dec 2019 10:31:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157593507544.2098.9687007201578884820.idtracker@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.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 10:31:36 -0000 Hi Jen, Thank you for sharing this updated version. Below some points that I do thi= nk need more clarification in the I-D:=20 (1) The document is too NAT64 centric. The proposal may apply as well for o= ther IPv6-only deployment scenarios (typically, unmanaged IPv6-only CPEs wi= th IPv4aaS). (2) A discussion on the benefit of this extra signal compared to relying on= existing signals (pref64, aftr_name, map_container...). For example, a hos= t that supports the option is ready to wait at minimum 300s and disable its= IPv4 configuration regardless of what is happening on the IPv6 leg. How is= that superior to a host delaying DHCP process by xxx ms should be explaine= d further. =20 (3) How "IPv6-only preferred" mode is supposed to be set at the host side: =3D=3D A DHCP client SHOULD allow a device administrator to configure IPv6-only preferred mode either for a specific interface (to indicate that the device is IPv6-only capable if connected to a NAT64 network via that interface) or for all interfaces. =20 =3D=3D * I guess the default value when the option is supported by a host is to di= sable including it in the request. The document should include a discussion= on the default behavior.=20 * If an explicit action is needed from the user to enable including the opt= ion, having a discussion to what extent the feature is likely to be enabled= would be needed. (4) The document is still mixing the DHCP client vs. host behaviors. For ex= ample,=20 Clients not capable of operating in an IPv6-only NAT64 environment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MUST NOT include the IPv6-only Preferred option in the Parameter Request List of any DHCP packets and MUST ignore that option in packets received from DHCP servers. does not make sense for a DHCP client.=20 Also, how the host is able to assess/determine that it is (not) capable to = behave in the IPv6 mode?=20 (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RFC8585= says the following:=20 "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition technologies for delivering IPv4 in IPv6-only connectivity. While yours is:=20 IPv4-as-a-Service: a deployment scenario when end hosts are expected to operate in IPv6-only mode by default and IPv4 addresses can be assigned to some hosts if those hosts explicitly opt-in to receiving IPv4 addresses. (6) Do you consider a host with CLAT function as an IPv6-only host? If so, the following definition should be updated to refer to "IPv4 connect= ivity" rather than "IPv4" in general. This is because an IPv4 address is re= quired for CLAT for example. =3D=3D IPv6-only capable host: a host which does not require IPv4 and can operate on IPv6-only networks. =3D=3D (7) Wouldn't the following add an extra delay for applications requiring CL= AT? =3D=3D The host MAY disable IPv4 stack completely for V6ONLY_WAIT seconds or until the network disconnection event happens. =3D=3D (8) Consider returning an address from the range defined in RFC7335 for IPv= 6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only ho= sts (those with a CLAT for example). =3D=3D=3D=3D The result is that 192.0.0.0/29 may be used in any system that requires IPv4 addresses for backward compatibility with IPv4 communications in an IPv6-only network but does not emit IPv4 packets "on the wire". =3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova > Envoy=E9=A0: mardi 10 d=E9cembre 2019 01:02 > =C0=A0: dhcwg@ietf.org > Cc=A0: V6 Ops List > Objet=A0: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only= - > 01.txt >=20 > Hello, >=20 > Thanks to everyone for very productive centi-thread on > draft-link-dhc-v6only-00 ;) > Here is the improved version, -01. >=20 > The main changes: >=20 > - The option is not zero length anymore. It has 4-bytes value which > might contain V6ONLY_WAIT timer. Benefits: > --- allows the network administrators to pilot the changes and > rollback quickly if needed; > --- addressed some concern about an option having zero length > (allegedly it might confuse some clients) >=20 > - Using a dedicated address to return to clients is now an optional > optimisation. By default the server is expected just to return a > random address (as usual). >=20 > - Typos fixed (probably some new typos added though). >=20 > The authors would like the DHC WG to consider adopting this document. >=20 > Thank you! >=20 > ---------- Forwarded message --------- > From: > Date: Tue, Dec 10, 2019 at 10:44 AM > Subject: New Version Notification for draft-link-dhc-v6only-01.txt > To: Tomek Mrugalski , Lorenzo Colitti > , Jen Linkova , Michael C. > Richardson >=20 >=20 >=20 > A new version of I-D, draft-link-dhc-v6only-01.txt > has been successfully submitted by Jen Linkova and posted to the > IETF repository. >=20 > Name: draft-link-dhc-v6only > Revision: 01 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-09 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6on= ly > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6only= -01 >=20 > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining an IPv4 > address if the network provides IPv6 connectivity. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Dec 10 06:04:04 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC8C1200B7; Tue, 10 Dec 2019 06:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AOqd09C-etQW; Tue, 10 Dec 2019 06:04:01 -0800 (PST) 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 D8A441200B6; Tue, 10 Dec 2019 06:04:01 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBAE0lWU030540; Tue, 10 Dec 2019 09:03:54 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2wsxpffeh4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 09:03:53 -0500 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 xBAE3qAt029893; Tue, 10 Dec 2019 09:03:52 -0500 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 xBAE3lZb029775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Dec 2019 09:03:48 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 69D01400A0A3; Tue, 10 Dec 2019 14:03:47 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 54DD5400A0A2; Tue, 10 Dec 2019 14:03:47 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 09:03:47 -0500 From: "STARK, BARBARA H" To: "'Lorenzo Colitti'" , "'Tomek Mrugalski'" CC: "'draft-link-dhc-v6only@ietf.org'" , "'V6 Ops List'" , "'dhcwg@ietf.org'" Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option Thread-Index: AQHVrviyNnjuBtjdnEKBlEHMXYbjcaey7X6AgAB01rA= Date: Tue, 10 Dec 2019 14:03:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153706A13@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <67155c63-2442-2846-57f2-82fa4da16251@marples.name> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.71.224] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61153706A13GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-10_03:2019-12-10,2019-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxlogscore=785 mlxscore=0 malwarescore=0 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912100122 Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 14:04:03 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61153706A13GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBEZWMgMTAsIDIwMTkgYXQgMTA6MjUgQU0gVG9tZWsgTXJ1Z2Fsc2tpIDx0b21hc3ou bXJ1Z2Fsc2tpQGdtYWlsLmNvbTxtYWlsdG86dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+PiB3 cm90ZToNClRoYXQncyBhIGdvb2QgYW5hbG9neS4gV291bGQgaXQgYmUgaGVscGZ1bCBpZiB0aGUg VjZPTkxZX1dBSVQgZGVzY3JpcHRpb24gd2FzIHVwZGF0ZSB0byBzYXkgc29tZXRoaW5nIHNpbWls YXIgdG86ICJVcG9uIHJlY2VwdGlvbiBvZiB0aGUgVjZPTkxZX1dBSVQgb3B0aW9uLCB0aGUgY2xp ZW50IHNldHMgaXRzIHJldmVydHMgYmFjayB0byBESENQRElTQ09WRVIgcmV0cmFuc21pc3Npb24g YW5kIHNldHMgaXRzIHJldHJhbnNtaXNzaW9uIHRpbWVyIHRvIFY2T05MWV9XQUlUIHNlY29uZHMi Pw0KDQpJZiBpdCBzZXRzIGl0cyByZXRyYW5zbWlzc2lvbiB0aW1lciB0byBWNk9OTFlfV0FJVCBz ZWNvbmRzLCB0aGVuIGlmIHRoZSBmaXJzdCBkaXNjb3ZlciBpcyBkcm9wcGVkLCB3aWxsIHRoZSBz ZWNvbmQgb25lIGJlIFY2T05MWV9XQUlUIHNlY29uZHMgYWZ0ZXIgdGhhdD8gVGhhdCBzZWVtcyBi YWQuIE9uY2UgdGhlIFY2T05MWV9XQUlUIHRpbWVyIGZpcmVzLCB3ZSB3YW50IHRoZSByZXRyYW5z bWlzc2lvbiBpbnRlcnZhbCB0byBiZSBiYWNrIHRvIGEgbG93IHZhbHVlLCBsaWtlIDEtMiBzZWNv bmRzLCByaWdodD8NCg0KUGVyaGFwcyBpdCdzIHBvb3JseSBuYW1lZCwgYnV0IGl0J3MgdmVyeSBt dWNoIERIQ1B2NCBvcHRpb24uIFRoZSBvcHRpb24gaXMgbm90IHN1cHBvc2VkIHRvIGFmZmVjdCBh bnkgSVB2NiBiZWhhdmlvci4NCg0KSG93IGFib3V0IGNhbGxpbmcgaXQgd2hhdCBpdCByZWFsbHkg aXM6IERJU0FCTEVWND8NCg0KSXQncyBub3QganVzdCAiZGlzYWJsZSBJUHY0Ii4gSXQncyAiZGlz YWJsZSBJUHY0LCBiZWNhdXNlIHlvdSB0aGVyZSdzIHRoaXMgb3RoZXIgdGhpbmcgaW5zdGVhZCIu IFNlZSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RoY3dnL1hjMHlRSVhX a0tNQ0xseGhNLUJwMEVXMFA3dzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3JnX2FyY2hfbXNnX2RoY3dnX1hjMHlR SVhXa0tNQ0xseGhNLTJEQnAwRVcwUDd3JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJ ZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT00ZDI0ZU5ISkhBRUZTX1kzLUNpcGRacTgwZ3lR eFhUMVZHZmVMYzlsa2NFJnM9VVp4MmxRckdVQ2MxcmxlWG56clhwdjhBVDJqSjFxTlZwNENDbjk0 T3B3VSZlPT4gYW5kIGZvbGxvdy11cHMuDQoNCjxiaHM+IElzIGl0IHJlYWxseSDigJxkaXNhYmxl IElQdjQgLi4u4oCdIG9yIOKAnGRpc2FibGUgREhDUHY0IGFkZHJlc3MgYWNxdWlzaXRpb24gZm9y IGEgd2hpbGXigJ0/IEkgdGhvdWdodCBob3N0cyB3ZXJlIHN0aWxsIGZyZWUgdG8gdXNlIGF1dG9j b25maWd1cmVkIElQdjQgYWRkcmVzc2VzICgxNjkuMjU0LngueCkgb24gdGhlIExBTi4gSSBhc2sg YmVjYXVzZSBJIGRvbuKAmXQgd2FudCB0byBnbyBkb3duIHRoYXQgcmF0LWhvbGUgb2YgcGVvcGxl IHRoaW5raW5nIGl0IG1pZ2h0IGJlIG9rIGZvciByb3V0ZXJzIHRvIHN0YXJ0IGJsb2NraW5nIGV2 ZXJ5dGhpbmcgb24gdGhlIElQdjQgZXRoZXJ0eXBlIGlmIHRoaXMgb3B0aW9uIGlzIHNlbnQgZnJv bSB0aGUgcm91dGVy4oCZcyBESENQdjQgc2VydmVyLiBXZeKAmXJlIGp1c3QgdHJ5aW5nIHRvIHNh dmUgb24gREhDUHY0IGFkZHJlc3MgYXNzaWdubWVudCB3aXRoIHRoaXMsIGFyZW7igJl0IHdlPw0K --_000_2D09D61DDFA73D4C884805CC7865E61153706A13GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAxMCwgMjAx OSBhdCAxMDoyNSBBTSBUb21layBNcnVnYWxza2kgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21hc3ou bXJ1Z2Fsc2tpQGdtYWlsLmNvbSI+dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGF0J3MgYSBnb29kIGFuYWxvZ3kuIFdvdWxkIGl0IGJlIGhlbHBmdWwg aWYgdGhlIFY2T05MWV9XQUlUIGRlc2NyaXB0aW9uIHdhcyB1cGRhdGUgdG8gc2F5IHNvbWV0aGlu ZyBzaW1pbGFyIHRvOiAmcXVvdDtVcG9uIHJlY2VwdGlvbiBvZiB0aGUgVjZPTkxZX1dBSVQgb3B0 aW9uLCB0aGUgY2xpZW50IHNldHMgaXRzIHJldmVydHMgYmFjayB0byBESENQRElTQ09WRVIgcmV0 cmFuc21pc3Npb24gYW5kIHNldHMgaXRzIHJldHJhbnNtaXNzaW9uDQogdGltZXIgdG8gVjZPTkxZ X1dBSVQgc2Vjb25kcyZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0IHNldHMgaXRzIHJldHJhbnNtaXNzaW9uIHRp bWVyIHRvIFY2T05MWV9XQUlUIHNlY29uZHMsIHRoZW4gaWYgdGhlIGZpcnN0IGRpc2NvdmVyIGlz IGRyb3BwZWQsIHdpbGwgdGhlIHNlY29uZCBvbmUgYmUmbmJzcDtWNk9OTFlfV0FJVCBzZWNvbmRz IGFmdGVyIHRoYXQ/IFRoYXQgc2VlbXMgYmFkLiBPbmNlIHRoZSBWNk9OTFlfV0FJVCB0aW1lciBm aXJlcywgd2Ugd2FudCB0aGUgcmV0cmFuc21pc3Npb24gaW50ZXJ2YWwNCiB0byBiZSBiYWNrIHRv IGEgbG93IHZhbHVlLCBsaWtlIDEtMiBzZWNvbmRzLCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBpdCdzIHBv b3JseSBuYW1lZCwgYnV0IGl0J3MgdmVyeSBtdWNoIERIQ1B2NCBvcHRpb24uIFRoZSBvcHRpb24g aXMgbm90IHN1cHBvc2VkIHRvIGFmZmVjdCBhbnkgSVB2NiBiZWhhdmlvci48YnI+DQo8YnI+DQpI b3cgYWJvdXQgY2FsbGluZyBpdCB3aGF0IGl0IHJlYWxseSBpczogRElTQUJMRVY0PyA8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 J3Mgbm90IGp1c3QgJnF1b3Q7ZGlzYWJsZSBJUHY0JnF1b3Q7LiBJdCdzICZxdW90O2Rpc2FibGUg SVB2NCwgYmVjYXVzZSB5b3UgdGhlcmUncyB0aGlzIG90aGVyIHRoaW5nIGluc3RlYWQmcXVvdDsu IFNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2dfZGhjd2dfWGMweVFJ WFdrS01DTGx4aE0tMkRCcDBFVzBQN3cmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1U U1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT00ZDI0ZU5ISkhBRUZT X1kzLUNpcGRacTgwZ3lReFhUMVZHZmVMYzlsa2NFJmFtcDtzPVVaeDJsUXJHVUNjMXJsZVhuenJY cHY4QVQyakoxcU5WcDRDQ245NE9wd1UmYW1wO2U9Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL2RoY3dnL1hjMHlRSVhXa0tNQ0xseGhNLUJwMEVXMFA3dzwvYT4NCiBhbmQg Zm9sbG93LXVwcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O2JocyZndDsgSXMgaXQgcmVh bGx5IOKAnGRpc2FibGUgSVB2NCAuLi7igJ0gb3Ig4oCcZGlzYWJsZSBESENQdjQgYWRkcmVzcyBh Y3F1aXNpdGlvbiBmb3IgYSB3aGlsZeKAnT8gSSB0aG91Z2h0IGhvc3RzIHdlcmUgc3RpbGwgZnJl ZSB0byB1c2UgYXV0b2NvbmZpZ3VyZWQgSVB2NCBhZGRyZXNzZXMgKDE2OS4yNTQueC54KSBvbiB0 aGUgTEFOLiBJIGFzayBiZWNhdXNlIEkgZG9u4oCZdCB3YW50IHRvIGdvIGRvd24gdGhhdCByYXQt aG9sZQ0KIG9mIHBlb3BsZSB0aGlua2luZyBpdCBtaWdodCBiZSBvayBmb3Igcm91dGVycyB0byBz dGFydCBibG9ja2luZyBldmVyeXRoaW5nIG9uIHRoZSBJUHY0IGV0aGVydHlwZSBpZiB0aGlzIG9w dGlvbiBpcyBzZW50IGZyb20gdGhlIHJvdXRlcuKAmXMgREhDUHY0IHNlcnZlci4gV2XigJlyZSBq dXN0IHRyeWluZyB0byBzYXZlIG9uIERIQ1B2NCBhZGRyZXNzIGFzc2lnbm1lbnQgd2l0aCB0aGlz LCBhcmVu4oCZdCB3ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E61153706A13GAALPA1MSGUSRBF_-- From nobody Tue Dec 10 06:38:50 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6951200E5 for ; Tue, 10 Dec 2019 06:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 L7G-Tf1ZkC9S for ; Tue, 10 Dec 2019 06:38:46 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2491200C3 for ; Tue, 10 Dec 2019 06:38:45 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id h14so9142248pfe.10 for ; Tue, 10 Dec 2019 06:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=HwG1Xl03ycN7hCFp6vJC3s+OOHtDk0Yr0RwmhP6adIc=; b=fmnUdOgnyWGtDm2L81oZlF5q57ejKMGVPLxiJGXXIxWT2Nfe5UNLE3F0d1fQXMUwxZ FoiuWGkDwyPkPSqySuJNpwlRwZDXKJsvUKApil0EDzoZrpxInkpI1SEn9CnnzWonRsx5 BAr9rbbSW0+f1BAq54YKCHkjXm6ayntiuOAMVaUCHq6B36TbpCsPsKf/IfBXUBz7p10j soaJyuwI+BxOyOyuuJ3JBE/haSoI4SgDzU7OeiiY+G+uUYb58raQAULrt83Q4LunSbA8 mmyWbnA5CpW/SYOIjQnNou4TBZMdNdN/Txpx+dq1JedWLhyGbt5ac0iBP8/2UKQUKID0 1fww== 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 :subject:date:message-id:references:cc:in-reply-to:to; bh=HwG1Xl03ycN7hCFp6vJC3s+OOHtDk0Yr0RwmhP6adIc=; b=V321r5G/SISGK5oY0lcKqCeCKRSLqCtR6uKcM0Az9dAodC+cfZq9hq57Al3M0pnshv JUqULCPBXCK0qsn09tiilb+qmzj+iz3CqYHodUQV7QFE1k1Wz+H+nQXDd9Pxwaw9fqPk tLAyqZnUjaB1bBjgHU7FY3L+YPyEk74mY4dI5zZSMnKldsrnZhIedfCXa8ui7QNj04j2 CJQmNPI6aMeoHMJP84XIIZbsJDjTL9FRYhBu4Xj9C7hAjZJ7F20pzdySVBvhwaPGvgnt 21hGlko9oZvkhsMFkxb8u/vNA+83A4tvCXZpim4C1TXZTcLm/+rv6NDygvG2rYDTxgHb BPBw== X-Gm-Message-State: APjAAAVTqQN4zn7M8uWDJDyjgTHeOTIxxdxBh72BmzakFgaRxl07bTqR drmhEZFFxvNNdqhdW9+SnYCs5UVwmr0= X-Google-Smtp-Source: APXvYqyyjyHE4dHCKxFH7Rtu+YH7WDNe8nmzluivCLJ7CCL0hnma4+YnauqsgF0suNa2A4V2FweiPA== X-Received: by 2002:a63:b005:: with SMTP id h5mr24280821pgf.67.1575988725347; Tue, 10 Dec 2019 06:38:45 -0800 (PST) Received: from ?IPv6:2600:380:4442:7fdc:b49b:b79c:d253:25a3? ([2600:380:4442:7fdc:b49b:b79c:d253:25a3]) by smtp.gmail.com with ESMTPSA id p16sm3664324pgm.8.2019.12.10.06.38.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2019 06:38:44 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C067CF90-A756-4EA2-8C95-69015505B5B6 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 10 Dec 2019 06:38:43 -0800 Message-Id: References: <2D09D61DDFA73D4C884805CC7865E61153706A13@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Lorenzo Colitti , Tomek Mrugalski , "draft-link-dhc-v6only@ietf.org" , V6 Ops List , "dhcwg@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153706A13@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 14:38:49 -0000 --Apple-Mail-C067CF90-A756-4EA2-8C95-69015505B5B6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good point. We=E2=80=99re wrestling with the same thing for ipv6 right now.=20= > On Dec 10, 2019, at 06:04, STARK, BARBARA H wrote: >=20 > =EF=BB=BF > On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski wrote: > That's a good analogy. Would it be helpful if the V6ONLY_WAIT description w= as update to say something similar to: "Upon reception of the V6ONLY_WAIT op= tion, the client sets its reverts back to DHCPDISCOVER retransmission and se= ts its retransmission timer to V6ONLY_WAIT seconds"? > =20 > If it sets its retransmission timer to V6ONLY_WAIT seconds, then if the fi= rst discover is dropped, will the second one be V6ONLY_WAIT seconds after th= at? That seems bad. Once the V6ONLY_WAIT timer fires, we want the retransmis= sion interval to be back to a low value, like 1-2 seconds, right? > =20 > Perhaps it's poorly named, but it's very much DHCPv4 option. The option is= not supposed to affect any IPv6 behavior. >=20 > How about calling it what it really is: DISABLEV4? > =20 > It's not just "disable IPv4". It's "disable IPv4, because you there's this= other thing instead". See https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQ= IXWkKMCLlxhM-Bp0EW0P7w and follow-ups. > =20 > Is it really =E2=80=9Cdisable IPv4 ...=E2=80=9D or =E2=80=9Cdisable D= HCPv4 address acquisition for a while=E2=80=9D? I thought hosts were still f= ree to use autoconfigured IPv4 addresses (169.254.x.x) on the LAN. I ask bec= ause I don=E2=80=99t want to go down that rat-hole of people thinking it mig= ht be ok for routers to start blocking everything on the IPv4 ethertype if t= his option is sent from the router=E2=80=99s DHCPv4 server. We=E2=80=99re ju= st trying to save on DHCPv4 address assignment with this, aren=E2=80=99t we?= > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-C067CF90-A756-4EA2-8C95-69015505B5B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Good point. We=E2=80=99re w= restling with the same thing for ipv6 right now. 

On Dec 10, 2019, at 06:04, STARK, BARBARA H &= lt;bs7652@att.com> wrote:

=EF=BB=BF

On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski <= tomasz.mrugalski@gmail.com= > wrote:

That's a good analogy. Would it be helpful if the V6O= NLY_WAIT description was update to say something similar to: "Upon reception= of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER= retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"?

 

If it sets its retransmission timer to V6ONLY_WAIT se= conds, then if the first discover is dropped, will the second one be V6= ONLY_WAIT seconds after that? That seems bad. Once the V6ONLY_WAIT timer fir= es, we want the retransmission interval to be back to a low value, like 1-2 seconds, right?

 

Perhaps it's poorly named, but it's very much DHCPv4 o= ption. The option is not supposed to affect any IPv6 behavior.

How about calling it what it really is: DISABLEV4?

 

It's not just "disable IPv4". It's "disable IPv4, bec= ause you there's this other thing instead". See http= s://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w and follow-ups.

 

<bhs> Is it really =E2=80=9Cdisable IPv4 ...=E2= =80=9D or =E2=80=9Cdisable DHCPv4 address acquisition for a while=E2=80=9D? I= thought hosts were still free to use autoconfigured IPv4 addresses (169.254= .x.x) on the LAN. I ask because I don=E2=80=99t want to go down that rat-hol= e of people thinking it might be ok for routers to start blocking everything o= n the IPv4 ethertype if this option is sent from the router=E2=80=99s DHCPv4= server. We=E2=80=99re just trying to save on DHCPv4 address assignment with= this, aren=E2=80=99t we?

_______________________________________________
v6ops m= ailing list
v6ops@ietf.org
https://www.ietf.= org/mailman/listinfo/v6ops
= --Apple-Mail-C067CF90-A756-4EA2-8C95-69015505B5B6-- From nobody Tue Dec 10 07:41:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4289120045; Tue, 10 Dec 2019 07:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=Ayw7uZnD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nrMCP9TZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5tQRNipgpVa; Tue, 10 Dec 2019 07:41:11 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447F31200DB; Tue, 10 Dec 2019 07:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12441; q=dns/txt; s=iport; t=1575992471; x=1577202071; h=from:to:subject:date:message-id:mime-version; bh=GRZPHkJSNbUOwX+qwnhd/n5h6LEemITTYYrexUuF+Vk=; b=Ayw7uZnDHIYkQJe0yIFsu9ZQ7CWxoVLzAfzGL4luVt3Yv95VAI05GZBW H/bSKrmYyHBnNxjmwlqw9FumchvyxucrSqMvafPpgqogOmwvt9JjrE6Ho vggMmEpZTjG/zf64irZWoYj1vBE336cdvanUm2EGnThA4NItI7xu4Cl1h Y=; X-Files: ATT00001.txt : 130 X-IPAS-Result: =?us-ascii?q?A0CVAAA9vO9d/5xdJa1lHAEBAQEBBwEBEQEEBAEBgWoHA?= =?us-ascii?q?QELAYEbL1AFbFggBAsqCoc/A4RahitOlTWEYoEugSQDVAIHAQEBDAEBGAEKC?= =?us-ascii?q?gIBAYRAAoIDJDQJDgIDAQEBAwIDAgEBBAEBAQIBBQRthTcMhV4BAQEBBAEQC?= =?us-ascii?q?xATAQEsDBEBGQQBATElCx0JAQQBEggGFIMBgkYDLgECDKJnAoE4iGGCJ4J+A?= =?us-ascii?q?QEFgUlBgwcYghAHAwaBNgGFG4Z8GoIAgViCTD6BBIFgAQEDAYFhFRaDFYIsj?= =?us-ascii?q?UOIOIESl1sKgi+DVII2NGWOaIJCh3aPfwGEP4kcC2SIRZFsAgQCBAUCDgEBB?= =?us-ascii?q?YFSOYFYcBU7gmxQERSMZoNzhRSFP3SBKIxzAYEPAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A+JHnCxJNJPDhNqoqR9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.69,164,1571702400"; d="txt'?scan'208,217";a="398574970" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 15:40:55 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAFesfe007237 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 15:40:55 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 09:40:54 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 09:40:53 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 09:40:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mj+PQuvUyW/z8JrtReXexyE3aaPgOyPiUqIa9euiqVOwTZWsvb3niLYFUi/MPYle48V6HQ75sLqmvPpg+Ye2Vk/2KpE3jNkQPRiXaJfAsf6s7oPaeAkOlLheI/cA1m4V3Gtn6lM3cMFfmv87t7nUZDpA7pJkpyvtf/m1Dd6/45ddyikg9IjpyasPamFsuN6YQap41zHZAFL7oZcC26AlSKtQlqjp49qesEj3XPY9zQ3JiFQZfZ6dq04q8wU3INX+z5WGxD+VNLPuzQ22q9L7lo9c/drN6KC76N57uEn+JkfCz9gwcJgcn9ffKfybDXopwaQe24DZ6qCX5TwBNvKIqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AIgIyQ4Xdu8Hz7ta/xMtqWl4QqsfeihM3KLwdxsDdaw=; b=dJyZCImmJitC+oR97/4Tai3nxjn94u/RhPiR6R/8/YibXU64syMpPDFk+LwnerD/jAWCEs9XYNkP4If2f/qIHT1P31AylERWutfOpqKoekJcjqZ4ftSllNP50BcgChPAx40db8q4+6PSlqRVpBNk6uxHzehDisTl+JUiDVflny7fcjWo5fnN227Qs0FYVqJ/QwbeddOM0VIF5gx+ZYzBGw72if4jQ1A03TSUlWwU47hLtG2IlzabGhnJfl7iLvDSP1DIBeEMjr0Mm58nxnu9J3izKvsMLW23MJNrdk0OqRDX2FC15I3oeh9LSiaaA78yQP/JWnGPkAsHQhrrOvyw5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AIgIyQ4Xdu8Hz7ta/xMtqWl4QqsfeihM3KLwdxsDdaw=; b=nrMCP9TZLCGvSwZUZUc+FBQFl6S7GOUcJ3TM8jKfNDrK8Wwhcpxwc0xVC7ftLVuXWpguVonr/yFtrX66gbwDjTzhbh/PxIV7C0jbJru7QKU1VGZZh1rXn2pfoSBHFBXVG2/pMjYcaX/B5IKspASaNNj9aKP45iT2VoQqRm3A8XQ= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4475.namprd11.prod.outlook.com (52.132.248.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Tue, 10 Dec 2019 15:40:52 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 15:40:52 +0000 From: "Bernie Volz (volz)" To: "v6ops@ietf.org" , 6man Chairs <6man-chairs@ietf.org> Thread-Topic: FYI - DHC WG: Adoption call for draft-link-dhc-v6only - Respond by Dec 24, 2019 Thread-Index: AdWvcCAwSOh1mAo1SAOuA0LPZl5Zpw== Date: Tue, 10 Dec 2019 15:40:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [161.44.67.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 924748dd-6d93-4740-44ff-08d77d875673 x-ms-traffictypediagnostic: DM6PR11MB4475: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(396003)(376002)(136003)(39860400002)(51874003)(189003)(199004)(4744005)(2906002)(110136005)(6506007)(7696005)(186003)(53546011)(26005)(8676002)(81156014)(8936002)(316002)(71200400001)(86362001)(64756008)(76116006)(66446008)(66476007)(66616009)(66946007)(450100002)(9686003)(66556008)(55016002)(33656002)(5660300002)(478600001)(81166006)(966005)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4475; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C7Mk8B7sXyfWd3MyEMajQwSETYeBkShHgfv5+Tzdal+2ZgTYd9mrTPQRKi7g8U/mbJq0w7eSAm7Ig9GPci4sTHl9ltjKAtXxYI4GiBP+nA2uRQAsb+BUMmaEgf8FV8Xngf/H6odsqmVj++468F3KlYbG5OLrMRqHFlDmzqAcOlr1TBU8UbF0/FzJcLiR+V0mLQq7QkZ/EEMJcozTCfuYRTSE4603BiQoa51fQ0neeTQjG4901Gs52Ai2BLjywWxjIh/weoLT0gekrVN+eiTyRCNuaqHIhKMvIWl33m+SvH0djr2O8JKHuWcmOWWsSX/bNcMhNIzNWjzZUDf4v7LIsZ0Zrkv1kqepIClZRQ0+Bm3N074+Q4ob4RBwlmAIw1hkGGRDtGIXqMEl9GQzkWAKdWjkON/JQ3+JbRl8Cg3FYy/c8htrXpAYm/DkqKMRYNyuti79NLy2n+1ZO7Ic/ZXJCf6llX1WpAz694wk72Xyq39IBsSJ0qm79NgYtBt9i/l4RB8+yWrf8uzkdgYILCiQqXAuuQ3n1iccmwkcD1gnPI0= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 924748dd-6d93-4740-44ff-08d77d875673 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 15:40:51.9407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +HPuDyLw3It7TN7FKRoPtBp6vg9Qh1T+hKYJbFbdGzwiNYmWu4/VA05tQcej1WfY X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4475 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [v6ops] FYI - DHC WG: Adoption call for draft-link-dhc-v6only - Respond by Dec 24, 2019 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 15:41:13 -0000 --_004_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_" --_000_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just as an FYI as this document has been discussed on these lists as well. * Bernie From: dhcwg On Behalf Of Bernie Volz (volz) Sent: Tuesday, December 10, 2019 10:36 AM To: dhcwg@ietf.org Subject: [dhcwg] Adoption call for draft-link-dhc-v6only - Respond by Dec 2= 4, 2019 Hello: You no doubt have seen the discussion here on the DHC WG mailing list for t= his draft - https://datatracker.ietf.org/doc/draft-link-dhc-v6only/. There = has also been some discussion on the v6ops and 6man mailing lists regarding= it. This starts the call for Adoption of this document. Please respond by Decem= ber 24, 2019. Our AD supports the DHC WG adopting this work and believes that the DHC WG = is the best place to do this work. Thanks in advance for your consideration of whether the WG should or should= not adopt this document as a work item. * Bernie (for DHC WG) --_000_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just as an FYI as this document has been discussed o= n these lists as well.

 

  • Bernie

 

From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, December 10, 2019 10:36 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Adoption call for draft-link-dhc-v6only - Respond b= y Dec 24, 2019

 

Hello:

 

You no doubt have seen the discussion here on the DH= C WG mailing list for this draft - https:/= /datatracker.ietf.org/doc/draft-link-dhc-v6only/. There has also been s= ome discussion on the v6ops and 6man mailing lists regarding it.=

 

This starts the call for Adoption of this document. = Please respond by December 24, 2019.

 

Our AD supports the DHC WG adopting this work and be= lieves that the DHC WG is the best place to do this work.

 

Thanks in advance for your consideration of whether = the WG should or should not adopt this document as a work item.<= /p>

 

  • Bernie (for DHC WG)
--_000_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_-- --_004_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Tue, 10 Dec 2019 15:37:53 GMT"; modification-date="Tue, 10 Dec 2019 15:37:53 GMT" Content-ID: <8765FCC94A13904A8020CD5049ECCCA3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1h aWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGhjd2cNCg== --_004_DM6PR11MB413796D38CF8003D19FE2C96CF5B0DM6PR11MB4137namp_-- From nobody Tue Dec 10 08:11:24 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87D1200E5; Tue, 10 Dec 2019 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=D68TsrzJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YW5srO1u Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGU1orS4LG5v; Tue, 10 Dec 2019 08:11:21 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D0A1200E0; Tue, 10 Dec 2019 08:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8423; q=dns/txt; s=iport; t=1575994281; x=1577203881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EMMTGfvGFUgpw8eXvUK5irmsQT9qgI6bc4E02CRAx4M=; b=D68TsrzJTPwdbDl4dPGaNSzTB/aTSHnbr8udQMbjMFGgVnJq6oNOFoPh hDFM+a4IOjeDHYQDDtiunWOP1umAlZOrIg5A/jMOQlYiZFoXGT0sOF4Vm OGAihNKFs20/ROdSvTSft8eFSFfs4pbG3FUim/u2BnA8IjvtpKjxdZ3i0 U=; IronPort-PHdr: =?us-ascii?q?9a23=3AySnWGRVNfUI/0tDsch6/kyupJTLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/cSs+DuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAABlw+9d/40NJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUskBScFbFggBAsqCoc/A4sFgl+JW44rglI?= =?us-ascii?q?DVAkBAQEMAQEYCwoCAQGEQAKCAyQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQE?= =?us-ascii?q?BAwEBEC4BASwJAgELBAIBCBEDAQEBKAchBgsUCQgCBAENBQgTB4I1TIJGAy4?= =?us-ascii?q?BAgyidwKBOIhhgieCfgEBBYE5Ag5BgwsNC4IXCYE2hRyGfBqCAIERR4JMPoI?= =?us-ascii?q?bSQEBAgEBGIExGINAgiyNOgeIXmCWdy9DCoIvhyOKLYQ7gkJ0hwKQAI5KiEW?= =?us-ascii?q?CF4tvg2YCBAIEBQIOAQEFgWkiN4EhcBUaIYJsCUcRFIxmBwIag1CFFIU/dAG?= =?us-ascii?q?BJ4xzAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,300,1571702400"; d="scan'208";a="379841184" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 16:11:20 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAGBKCW024317 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 16:11:20 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 10:11:19 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 11:11:18 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 10:11:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PUF3ScbJvD+oLAjcROnowm/JcpJ54A3P6livKyaR3CAtn7yeUnOZdUpsGCf/PtrEzSJ8RdToi0JlxTMia4OSZU9PNmxHaNFWo53S7PdfBKJ/HWtSPLmTmr7Y3O6CTxOn+85GaVXZQklSDz8pf55+4xpyGVJRs2t+UNxjDhgeV36Ajjdvb/mHwP+d5Yx1QA4N2Vd2Nyl6idym7Rok67wjPd0UcHDFMSDD2mNZ50Og1yvyCXUaErc9i4FU8h97E11oRxgG+61G71RwMyPO6D9fWnr4nY2qIAnFOWPa5VUiCEguR7O0biZZYJf1lKjujR0oiNLoKRuRjb1wlbd5yZi/kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9zhTjfoXFVdXmiF/A72XY2lzmR3+DPSnLPK/2GbVjA=; b=WF9vd63lJx1BIg7fzA/GHS0BvnKTUsOcECkVTx4D1hVqJAR51nNm8HPcTIkijY/Fp7ma6l7HLjT7Ulp71bfav/hSsynleP999SxKzxO5W+FAhHhpD+gmPcaAc4HgHFdX8Q1zA/LbmhlMfQgthsvLeXpzQyGCFU4uEVxkLO23KPoS/jg3IseQRkuIwIfUcfgAldI/rMwvio1cC34L8C15XEZVRiuCazwnOwMvYKbbeUzAwCjnmbg3MBAKCSxQUDvjJVehEaMHnlvDLiadVuAEgqxZ6XOwM+/mamD6O2EZRUnKJPpXjl8DRUyNrH6URDqfFQxCtmRXa6QwS0VA753pNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9zhTjfoXFVdXmiF/A72XY2lzmR3+DPSnLPK/2GbVjA=; b=YW5srO1uxFJHDLJh7YwP4cX05wPCk4U3DCmeIwDvHfhFZWZatpltE4QcaOs+lQQBh+91mkqBrFTCJUKLX22QDV8MTtVcuF6TmRZKcZq/RsngsMIVmYsDDv2LwgZtjI6DfCwZ3GovlXgOw49S/XhtwUM2CjPqg1e8o0wobsSslF4= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3466.namprd11.prod.outlook.com (20.176.123.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Tue, 10 Dec 2019 16:11:17 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 16:11:17 +0000 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" , Jen Linkova , "dhcwg@ietf.org" CC: V6 Ops List Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfA== Date: Tue, 10 Dec 2019 16:11:16 +0000 Message-ID: References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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=volz@cisco.com; x-originating-ip: [161.44.67.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72bb1441-85de-4ae1-8ada-08d77d8b9648 x-ms-traffictypediagnostic: DM6PR11MB3466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(346002)(376002)(366004)(189003)(54164003)(199004)(13464003)(8936002)(9686003)(81166006)(86362001)(966005)(33656002)(8676002)(81156014)(52536014)(19627235002)(2906002)(478600001)(26005)(186003)(110136005)(66556008)(76116006)(7696005)(316002)(4326008)(66476007)(66446008)(66946007)(71200400001)(53546011)(6506007)(15650500001)(5660300002)(55016002)(64756008)(66574012)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3466; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pzOul8RWnPlc9AoprgRWwuiYfapG5pfgdVW+I6BDTr/EXGiMA43CSOlQ5JM4ZxKW4rYNrlILPN6Y14hso8FaLTdKowzSc4fBV9hHEsz+Pyf9P2lQNoPoGoSCslw3nlhQXpFNzziQl2PRkP5cLo2oZqzmYFLRDw3E42ZEqI1XQm/QBD6X7XW0h3hdU2LmDA0XhxhYeOdYRlUsGaSAssi7rIJHzkqRZVcxWkh6HtjJhgrVloZQ9h0gb7BFfPkB8z03QcFMmL375FwNc4Shvl+pe2d/yeAZy9OXbK8jPK7VW26jfcxiY3mhLdmC0+I2tFPtpv3KayuudoQ2fYOJSpYTORPazFjye+KKWaAyz9zerLpoiPZM1gAqf1hmgCqeZc7HlVIWaaQc+m+nKrCY9SOAy9iGV3BJjWe/n5ztyXByhwbzhUNUK8rZ8LJ/Tb+Jo8cDoOqGSYyfCr2pK07IrUh8UeLMfVv3X9DtTyUBLyQDQF6g27IHXY9vxvPX1mM2QGzlBUk157GaxlDBtouJexJCEMMh8kxoRIIz1rF4B/Ek/ipRxMdUTcW396HlFYpeiLP6JrYyr+DDhclSu0XAJvCuoQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72bb1441-85de-4ae1-8ada-08d77d8b9648 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 16:11:16.9448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZWmElGz6PCDiHsNooUE9uc0vmuOjoKzjEULB2fJopb2F7MnMJJswpX1OA3684wP9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3466 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 16:11:23 -0000 Hi: Is (8): (8) Consider returning an address from the range defined in RFC7335 for IP= v6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only h= osts (those with a CLAT for example). =3D=3D=3D=3D The result is that 192.0.0.0/29 may be used in any system that requires IPv4 addresses for backward compatibility with IPv4 communications in an IPv6-only network but does not emit IPv4 packets "on the wire". =3D=3D=3D=3D But RFC7335 says (in section 4): IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], which is dedicated for DS-Lite. As defined in [RFC6333], this subnet is only present between the B4 and the Address Family Transition Router (AFTR) and never emits packets from this prefix "on the wire". <= --- 464XLAT has the same need for a non-routed IPv4 prefix, and this same need may be common for other similar solutions. It is most prudent and effective to generalize 192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6 transition technologies rather than reserving a prefix for every possible solution. So, this address is only used "on the host" (not on the wire), so why would= there be any need for the DHCP server to assign this address? And as the IPv6-only option means that the host never completes the DHCPDIS= COVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be used to as= sign any address. - Bernie -----Original Message----- From: dhcwg On Behalf Of mohamed.boucadair@orange.= com Sent: Tuesday, December 10, 2019 5:32 AM To: Jen Linkova ; dhcwg@ietf.org Cc: V6 Ops List Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6onl= y-01.txt Hi Jen, Thank you for sharing this updated version. Below some points that I do thi= nk need more clarification in the I-D:=20 (1) The document is too NAT64 centric. The proposal may apply as well for o= ther IPv6-only deployment scenarios (typically, unmanaged IPv6-only CPEs wi= th IPv4aaS). (2) A discussion on the benefit of this extra signal compared to relying on= existing signals (pref64, aftr_name, map_container...). For example, a hos= t that supports the option is ready to wait at minimum 300s and disable its= IPv4 configuration regardless of what is happening on the IPv6 leg. How is= that superior to a host delaying DHCP process by xxx ms should be explaine= d further. =20 (3) How "IPv6-only preferred" mode is supposed to be set at the host side: =3D=3D A DHCP client SHOULD allow a device administrator to configure IPv6-only preferred mode either for a specific interface (to indicate that the device is IPv6-only capable if connected to a NAT64 network via that interface) or for all interfaces. =20 =3D=3D * I guess the default value when the option is supported by a host is to di= sable including it in the request. The document should include a discussion= on the default behavior.=20 * If an explicit action is needed from the user to enable including the opt= ion, having a discussion to what extent the feature is likely to be enabled= would be needed. (4) The document is still mixing the DHCP client vs. host behaviors. For ex= ample,=20 Clients not capable of operating in an IPv6-only NAT64 environment ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MUST NOT include the IPv6-only Preferred option in the Parameter Request List of any DHCP packets and MUST ignore that option in packets received from DHCP servers. does not make sense for a DHCP client.=20 Also, how the host is able to assess/determine that it is (not) capable to = behave in the IPv6 mode?=20 (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RFC8585= says the following:=20 "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition technologies for delivering IPv4 in IPv6-only connectivity. While yours is:=20 IPv4-as-a-Service: a deployment scenario when end hosts are expected to operate in IPv6-only mode by default and IPv4 addresses can be assigned to some hosts if those hosts explicitly opt-in to receiving IPv4 addresses. (6) Do you consider a host with CLAT function as an IPv6-only host? If so, the following definition should be updated to refer to "IPv4 connect= ivity" rather than "IPv4" in general. This is because an IPv4 address is re= quired for CLAT for example. =3D=3D IPv6-only capable host: a host which does not require IPv4 and can operate on IPv6-only networks. =3D=3D (7) Wouldn't the following add an extra delay for applications requiring CL= AT? =3D=3D The host MAY disable IPv4 stack completely for V6ONLY_WAIT seconds or until the network disconnection event happens. =3D=3D (8) Consider returning an address from the range defined in RFC7335 for IPv= 6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only ho= sts (those with a CLAT for example). =3D=3D=3D=3D The result is that 192.0.0.0/29 may be used in any system that requires IPv4 addresses for backward compatibility with IPv4 communications in an IPv6-only network but does not emit IPv4 packets "on the wire". =3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova=20 > Envoy=E9=A0: mardi 10 d=E9cembre 2019 01:02 =C0=A0: dhcwg@ietf.org Cc=A0:= V6 Ops=20 > List Objet=A0: [dhcwg] Fwd: New Version Notification for=20 > draft-link-dhc-v6only- 01.txt >=20 > Hello, >=20 > Thanks to everyone for very productive centi-thread on > draft-link-dhc-v6only-00 ;) > Here is the improved version, -01. >=20 > The main changes: >=20 > - The option is not zero length anymore. It has 4-bytes value which=20 > might contain V6ONLY_WAIT timer. Benefits: > --- allows the network administrators to pilot the changes and=20 > rollback quickly if needed; > --- addressed some concern about an option having zero length=20 > (allegedly it might confuse some clients) >=20 > - Using a dedicated address to return to clients is now an optional=20 > optimisation. By default the server is expected just to return a=20 > random address (as usual). >=20 > - Typos fixed (probably some new typos added though). >=20 > The authors would like the DHC WG to consider adopting this document. >=20 > Thank you! >=20 > ---------- Forwarded message --------- > From: > Date: Tue, Dec 10, 2019 at 10:44 AM > Subject: New Version Notification for draft-link-dhc-v6only-01.txt > To: Tomek Mrugalski , Lorenzo Colitti=20 > , Jen Linkova , Michael C. > Richardson >=20 >=20 >=20 > A new version of I-D, draft-link-dhc-v6only-01.txt has been=20 > successfully submitted by Jen Linkova and posted to the IETF=20 > repository. >=20 > Name: draft-link-dhc-v6only > Revision: 01 > Title: IPv6-Only-Preferred Option for DHCP > Document date: 2019-12-09 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc-v6on= ly > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6only= -01 >=20 > Abstract: > This document specifies a DHCP option to indicate that a host > supports an IPv6-only mode and willing to forgo obtaining an IPv4 > address if the network provides IPv6 connectivity. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Dec 10 08:39:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C5120861 for ; Tue, 10 Dec 2019 08:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7_r09hNwvws for ; Tue, 10 Dec 2019 08:39:24 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA2D120857 for ; Tue, 10 Dec 2019 08:39:24 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id b19so122809pfo.2 for ; Tue, 10 Dec 2019 08:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qZQjG/DLihF/hJhGmP5vs76vBR3cxZrV3fGmzHGfMx0=; b=pS9wbLxnsM6WQ6J7l/h3AErMLvxPoM5ACdqG3njcsZofRFoaMo8lihH/Piv7BcCxBr XPOslewz5HX6G3VPa7A16QcDIsTQt5tM1BBN6nrLZ0q/ZyyBFAuDFK2wzAJTSJJWgLtG wHYVIF74hChNnIVSfb8rw3+BJilWYN/Mhl0sFmuMY1rqBxzKeA9fVM/rHxOKFYqE3oFN Zc/ZLAvwsaxPgSQIMz+iegf2qpBCmgsU8CZATbE55Sd6dpXLjyQmJNTBBvGfg0ls19J1 g4A4/9715iXyWFnFkK+QIntQjnqBwNaE6RFYqqICFiMV6GLrvqw/RxFM++JrBGZ1yjwO M+YQ== 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=qZQjG/DLihF/hJhGmP5vs76vBR3cxZrV3fGmzHGfMx0=; b=p3QgZNNcGvGuwmJW+aO+9ykO9Tu9d380FhT2ij9LMYw38+VzB7xHygVc/gFEy4zv89 zc0fWXEUT52kETiw8uC+4nMYUVRWwQoORfRn5m6if8V51g82qOj4P2kpM1v6x5HtZeOc TOR0BLN8Aj6MkbeDVcTkc+IpqGPY0EzfPIsJ4J5i8IJyhZZTypMawIbK5Ce7o0VelIns NQQNXvs+xHT3f/nocq2wyEFhpgMFaizQKY0bE1jWDRRG9o6g1pEhrlVTNkMQNtgmUGSD XiMO1bwDSyBNTmE6WSm7DAAp6P7YN6zXoab6Ix4ZGYnmEe6ZpJXDaVWfaXMI36vGFUEo FMnw== X-Gm-Message-State: APjAAAV0rkbUIj2d8mex0loBbUSpt7ZMKdxEevqvfs/iWHtpejmFLYYj p0ukmiy7HjjhJKYjd0s0AywK2KwWOYE= X-Google-Smtp-Source: APXvYqzd0OrSC8vBtyvhtGor8RfboxjTp2C0q1uSPOGd2i2reqQHMfn4p6lXTlmhwL80ZdiVC1/d1A== X-Received: by 2002:a63:de08:: with SMTP id f8mr25421425pgg.107.1575995963591; Tue, 10 Dec 2019 08:39:23 -0800 (PST) Received: from [17.192.139.178] ([17.192.139.178]) by smtp.gmail.com with ESMTPSA id j23sm4011651pfe.95.2019.12.10.08.39.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 08:39:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) From: Ted Lemon In-Reply-To: Date: Tue, 10 Dec 2019 08:39:21 -0800 Cc: "mohamed.boucadair@orange.com" , Jen Linkova , "dhcwg@ietf.org" , V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 16:39:26 -0000 I really think you should have a clear justification for doing anything = other than returning 0.0.0.0. Anything else is going to be more = complicated in the long term. The justification =E2=80=9Cbecause = 0.0.0.0 would be filtered out by the server=E2=80=9D seems like it=E2=80=99= s very implementation-dependent and not really that big a deal. Is = that your only reason? > On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) = wrote: >=20 > Hi: >=20 > Is (8): >=20 > (8) Consider returning an address from the range defined in = RFC7335 for IPv6-only hosts. Such IPv4 addresses are required anyway for = some IPv6-only hosts (those with a CLAT for example). >=20 > =3D=3D=3D=3D > The result is that 192.0.0.0/29 may be used in any system > that requires IPv4 addresses for backward compatibility with = IPv4 > communications in an IPv6-only network but does not emit IPv4 = packets > "on the wire". > =3D=3D=3D=3D >=20 > But RFC7335 says (in section 4): >=20 > IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], > which is dedicated for DS-Lite. As defined in [RFC6333], this = subnet > is only present between the B4 and the Address Family Transition > Router (AFTR) and never emits packets from this prefix "on the = wire". <--- > 464XLAT has the same need for a non-routed IPv4 prefix, and this = same > need may be common for other similar solutions. It is most prudent > and effective to generalize 192.0.0.0/29 for the use of supporting > IPv4 interfaces in IPv6 transition technologies rather than = reserving > a prefix for every possible solution. >=20 > So, this address is only used "on the host" (not on the wire), so why = would there be any need for the DHCP server to assign this address? >=20 > And as the IPv6-only option means that the host never completes the = DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be = used to assign any address. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg On Behalf Of = mohamed.boucadair@orange.com > Sent: Tuesday, December 10, 2019 5:32 AM > To: Jen Linkova ; dhcwg@ietf.org > Cc: V6 Ops List > Subject: Re: [dhcwg] Fwd: New Version Notification for = draft-link-dhc-v6only-01.txt >=20 > Hi Jen, >=20 > Thank you for sharing this updated version. Below some points that I = do think need more clarification in the I-D:=20 >=20 > (1) The document is too NAT64 centric. The proposal may apply as well = for other IPv6-only deployment scenarios (typically, unmanaged IPv6-only = CPEs with IPv4aaS). >=20 > (2) A discussion on the benefit of this extra signal compared to = relying on existing signals (pref64, aftr_name, map_container...). For = example, a host that supports the option is ready to wait at minimum = 300s and disable its IPv4 configuration regardless of what is happening = on the IPv6 leg. How is that superior to a host delaying DHCP process by = xxx ms should be explained further. =20 >=20 > (3) How "IPv6-only preferred" mode is supposed to be set at the host = side: >=20 > =3D=3D > A DHCP client SHOULD allow a device administrator to configure > IPv6-only preferred mode either for a specific interface (to = indicate > that the device is IPv6-only capable if connected to a NAT64 network > via that interface) or for all interfaces. =20 > =3D=3D >=20 > * I guess the default value when the option is supported by a host is = to disable including it in the request. The document should include a = discussion on the default behavior.=20 > * If an explicit action is needed from the user to enable including = the option, having a discussion to what extent the feature is likely to = be enabled would be needed. >=20 > (4) The document is still mixing the DHCP client vs. host behaviors. = For example,=20 >=20 > Clients not capable of operating in an IPv6-only NAT64 environment > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > MUST NOT include the IPv6-only Preferred option in the Parameter > Request List of any DHCP packets and MUST ignore that option in > packets received from DHCP servers. >=20 > does not make sense for a DHCP client.=20 >=20 > Also, how the host is able to assess/determine that it is (not) = capable to behave in the IPv6 mode?=20 >=20 > (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., = RFC8585 says the following:=20 >=20 > "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition > technologies for delivering IPv4 in IPv6-only connectivity. >=20 > While yours is:=20 >=20 > IPv4-as-a-Service: a deployment scenario when end hosts are expected > to operate in IPv6-only mode by default and IPv4 addresses can be > assigned to some hosts if those hosts explicitly opt-in to receiving > IPv4 addresses. >=20 > (6) Do you consider a host with CLAT function as an IPv6-only host? >=20 > If so, the following definition should be updated to refer to "IPv4 = connectivity" rather than "IPv4" in general. This is because an IPv4 = address is required for CLAT for example. >=20 > =3D=3D > IPv6-only capable host: a host which does not require IPv4 and can > operate on IPv6-only networks. > =3D=3D >=20 > (7) Wouldn't the following add an extra delay for applications = requiring CLAT? >=20 > =3D=3D > The host MAY disable IPv4 stack > completely for V6ONLY_WAIT seconds or until the network = disconnection > event happens. > =3D=3D >=20 > (8) Consider returning an address from the range defined in RFC7335 = for IPv6-only hosts. Such IPv4 addresses are required anyway for some = IPv6-only hosts (those with a CLAT for example). >=20 > =3D=3D=3D=3D > The result is that 192.0.0.0/29 may be used in any system > that requires IPv4 addresses for backward compatibility with IPv4 > communications in an IPv6-only network but does not emit IPv4 = packets > "on the wire". > =3D=3D=3D=3D >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova=20= >> Envoy=C3=A9 : mardi 10 d=C3=A9cembre 2019 01:02 =C3=80 : = dhcwg@ietf.org Cc : V6 Ops=20 >> List Objet : [dhcwg] Fwd: New Version Notification for=20 >> draft-link-dhc-v6only- 01.txt >>=20 >> Hello, >>=20 >> Thanks to everyone for very productive centi-thread on >> draft-link-dhc-v6only-00 ;) >> Here is the improved version, -01. >>=20 >> The main changes: >>=20 >> - The option is not zero length anymore. It has 4-bytes value which=20= >> might contain V6ONLY_WAIT timer. Benefits: >> --- allows the network administrators to pilot the changes and=20 >> rollback quickly if needed; >> --- addressed some concern about an option having zero length=20 >> (allegedly it might confuse some clients) >>=20 >> - Using a dedicated address to return to clients is now an optional=20= >> optimisation. By default the server is expected just to return a=20 >> random address (as usual). >>=20 >> - Typos fixed (probably some new typos added though). >>=20 >> The authors would like the DHC WG to consider adopting this document. >>=20 >> Thank you! >>=20 >> ---------- Forwarded message --------- >> From: >> Date: Tue, Dec 10, 2019 at 10:44 AM >> Subject: New Version Notification for draft-link-dhc-v6only-01.txt >> To: Tomek Mrugalski , Lorenzo Colitti=20 >> , Jen Linkova , Michael C. >> Richardson >>=20 >>=20 >>=20 >> A new version of I-D, draft-link-dhc-v6only-01.txt has been=20 >> successfully submitted by Jen Linkova and posted to the IETF=20 >> repository. >>=20 >> Name: draft-link-dhc-v6only >> Revision: 01 >> Title: IPv6-Only-Preferred Option for DHCP >> Document date: 2019-12-09 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt >> Status: = https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ >> Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6only-01 >>=20 >> Abstract: >> This document specifies a DHCP option to indicate that a host >> supports an IPv6-only mode and willing to forgo obtaining an IPv4 >> address if the network provides IPv6 connectivity. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >> -- >> SY, Jen Linkova aka Furry >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=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 From nobody Tue Dec 10 08:53:37 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197631208BC; Tue, 10 Dec 2019 08:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=PlsDmiDl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Fwb/4ils Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwzAJA_7OdvZ; Tue, 10 Dec 2019 08:53:35 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6AB1208B4; Tue, 10 Dec 2019 08:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13122; q=dns/txt; s=iport; t=1575996814; x=1577206414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S24CYgw/M+d2fL6bxdki7/R4qa+p+FMoAAYsd3XPnKQ=; b=PlsDmiDlcGsfcSxFGTcZmRUl03AuGI1J0TNri21TVIII6os5H3qkFbQP nf7vhQd4p2FdY+lknZ0sPyvTJC0SWqLhq5qcHKRWYx7ayIYYyr+mtiDg6 iAiZKY59IulT3asjVin8eKbCdCubfizx6qHIBL7UrZZ7f1QBv8Rkdihwq o=; IronPort-PHdr: =?us-ascii?q?9a23=3AIqUpvB8G33f5LP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98Rmlk+B8qXIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAAA5ze9d/4YNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX6BSyknBWxYIAQLKgqDeYNGA4sFgl+?= =?us-ascii?q?JW44rglIDVAkBAQEMAQEYCwoCAQGEQAIXgWwkOBMCAw0BAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVeAQEBAQIBAQEQEREMAQEsCQIBBAcEAgEIDgMDAQEBAQICIwMCAgIfBgs?= =?us-ascii?q?UAQgIAgQOBQgTB4I1TIJGAw4gAQIMo0ACgTiIYXWBMoJ+AQEFgTUBAwIOQYM?= =?us-ascii?q?RDQuCFwmBDiiFHIZ8GoIAgRFHgkw+ghtJAQECAQEYgTEYFYJ5MoIsjToHgme?= =?us-ascii?q?Fd5dXL0MKgi+HI4othDuCQnSHApAAlw+CF4tvg2YCBAIEBQIOAQEFgWkiN4E?= =?us-ascii?q?hcBUaIYJsCUcRFIxmBwIaFYM7hRSFP3QBgSeMcwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,300,1571702400"; d="scan'208";a="682206596" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 16:53:33 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAGrXao025840 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 16:53:33 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 10:53:32 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 10:53:32 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 11:53:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bIjAhInicvqz6hvJIBPrKEQOiC8kmohAmrpXw2y8LCC8yhWycRlImGFdczFLsoeoiOYbycJcrf/KTNmbozeNzNHAzQWRHobo42o40dqXqFevrDWcCXLI1P6D+vAN1rDE7IawCQyXAqxcBUeeZiawaFVIsijf3o1LyNG6Nm8qK8AT1LLZ/n3AzbR9GVZRdScMgXFyPmpvKjISECngLAa4QV0XuIVOvgC6oqo1921sAEvowdCK6gcsjHu8k4k2mOk2SEtU+qN9sOzRhRzFDV+IgpSNPvmgrPpA11xyoP8sB66BQMdUaCHggLLhyB6bdyj2jTya+HNjBMtc2y4R1GDzGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S24CYgw/M+d2fL6bxdki7/R4qa+p+FMoAAYsd3XPnKQ=; b=HRrdtYDU1tP0w1yag0rdFzxtOk4BACr3yufC5MMNGz9Q/ySC30y2VVGUzoPkjnzBvB3F7TaYs4dPusHw/p72SRsjuDHwK/RVJoGNijp5eiJpPjFdkacDc1uPx5P9jtgpPRNnwDT5evZL+0SC/os/JzDCFeE3VXEVcxt3lt5720wSd10pHHe/Sd7mjTmlvkoZByl5tzUaB9BuLyn3c/ULpMacOsTVw5gkB47V7Tp22DqaHCwxshy1V6eaEXbGGUpIZmpFV6yw6UOpVJu8bzWIi1GWrU1EateEiGOoA/Mxeb2y5giVw6XWoTuJdFKG4p+aCNgpNXs5TPupkkc0huvATQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S24CYgw/M+d2fL6bxdki7/R4qa+p+FMoAAYsd3XPnKQ=; b=Fwb/4ilsl5l++aBLmAyDPwR48Ks/QgIX28zmFPLSPDpZ5uVrEsV8audW0gEpsPFmBSWp1rVpmm7KB5MRUADtMjBCm1Y1Y0LNjQmcAIzcJOr3S50hsOvLenNmpDFLIjsVshiYItawlHNw5xio6Na+VANmxzSdfC/lde1aDIJpkfM= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB2987.namprd11.prod.outlook.com (20.177.217.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Tue, 10 Dec 2019 16:53:30 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 16:53:30 +0000 From: "Bernie Volz (volz)" To: Ted Lemon CC: "mohamed.boucadair@orange.com" , Jen Linkova , "dhcwg@ietf.org" , V6 Ops List Thread-Topic: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKezkdaAgAADwfA= Date: Tue, 10 Dec 2019 16:53:30 +0000 Message-ID: References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [161.44.67.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b32b15d-ec0a-4b35-1282-08d77d917c55 x-ms-traffictypediagnostic: DM6PR11MB2987: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(396003)(366004)(346002)(13464003)(54164003)(189003)(199004)(6506007)(52536014)(53546011)(26005)(7696005)(66476007)(5660300002)(81166006)(81156014)(8936002)(186003)(6916009)(19627235002)(64756008)(66446008)(8676002)(66574012)(66556008)(76116006)(66946007)(4326008)(478600001)(9686003)(316002)(55016002)(966005)(54906003)(2906002)(15650500001)(33656002)(86362001)(71200400001)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2987; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vscye/M+QQgqjIDy13OcqzeIFAGiXZjO2s1koxgQnLkdHBLCblI/cofW6mKVjR2e0yNsq9jBL2cXEPUCrNbkx4Y1d7gbg85PjoS+Ux3RTk3UPHZ45HrOK7uJCM4O9v3bxkT+mn9eP0vVX/YZqvc5GigEQLBbm4n7cHBoFXAmkyF/l/3Aos61EOVSHmTJiRWbNz39L1++O1oheOIh/KhOMbI3NzSgwd/Glq10xmZuTovDZSmQapVnxnNpSao8f0y6Cgq5KsDrqWyEwP+jRp2vP1yJD+IRGBcG/7brxF37n70jlDp0yneCYW4PGiIyAmkYIAJVEQ3n6ODJYfb9sBI9ceGzgbMDbrTI+iTmHPRFY2Cnm1ENKqwgJL7Oer903SsDIuWw29diQjEvlx0TEUlFLGzfyGRku1L8LWQxaC6yZJ0dQiVGgQ2irE/1oOcbJIffqMxfo5eTM26C7RVRBy/hz8dB3WU0TassNIewFDZoQx2bTwsXepVktR1Ryeus3TTtoyKOumOdhLVRP/lzPRYZkX1VvUnT1u8zoGYIU6qpr8uHyqX1Jijxq+x5kkvq6XPFDZ5jRN125lHdy+PRFrsimw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b32b15d-ec0a-4b35-1282-08d77d917c55 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 16:53:30.4655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dCmefTYJM6uEWSo8TzkC7sfDMBxrgCdc4VuNQEa4HsNI2MV0yz/UT1s1QZyQ2aei X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2987 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 16:53:37 -0000 SSd2ZSBkZWJhdGVkIHRoYXQgaXNzdWUgb24gZW5kIGFuZCBub3QgZ29pbmcgdG8gZG8gaXQgYW55 IGZ1cnRoZXIuIEkgY29tcGxldGVseSBkaXNhZ3JlZSAtIHNlcnZlciBzaG91bGQgcmV0dXJuIHdo YXRldmVyIGl0IHdvdWxkIGhhdmUgcmV0dXJuZWQgaWYgdGhlIG9wdGlvbiBpcyB3ZXJlIG5vdCBw cmVzZW50Lg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiANClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDEw LCAyMDE5IDExOjM5IEFNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4N CkNjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKZW4gTGlua292YSA8ZnVycnkxM0Bn bWFpbC5jb20+OyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFt2Nm9wc10gW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KDQpJIHJlYWxseSB0aGluayB5b3Ug c2hvdWxkIGhhdmUgYSBjbGVhciBqdXN0aWZpY2F0aW9uIGZvciBkb2luZyBhbnl0aGluZyBvdGhl ciB0aGFuIHJldHVybmluZyAwLjAuMC4wLiAgIEFueXRoaW5nIGVsc2UgaXMgZ29pbmcgdG8gYmUg bW9yZSBjb21wbGljYXRlZCBpbiB0aGUgbG9uZyB0ZXJtLiAgIFRoZSBqdXN0aWZpY2F0aW9uIOKA nGJlY2F1c2UgMC4wLjAuMCB3b3VsZCBiZSBmaWx0ZXJlZCBvdXQgYnkgdGhlIHNlcnZlcuKAnSBz ZWVtcyBsaWtlIGl04oCZcyB2ZXJ5IGltcGxlbWVudGF0aW9uLWRlcGVuZGVudCBhbmQgbm90IHJl YWxseSB0aGF0IGJpZyBhIGRlYWwuICAgSXMgdGhhdCB5b3VyIG9ubHkgcmVhc29uPw0KDQo+IE9u IERlYyAxMCwgMjAxOSwgYXQgODoxMSBBTSwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2Nv LmNvbT4gd3JvdGU6DQo+IA0KPiBIaToNCj4gDQo+IElzICg4KToNCj4gDQo+IAkoOCkgQ29uc2lk ZXIgcmV0dXJuaW5nIGFuIGFkZHJlc3MgZnJvbSB0aGUgcmFuZ2UgZGVmaW5lZCBpbiBSRkM3MzM1 IGZvciBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkIGFu eXdheSBmb3Igc29tZSBJUHY2LW9ubHkgaG9zdHMgKHRob3NlIHdpdGggYSBDTEFUIGZvciBleGFt cGxlKS4NCj4gDQo+IAk9PT09DQo+IAkgICBUaGUgcmVzdWx0IGlzIHRoYXQgMTkyLjAuMC4wLzI5 IG1heSBiZSB1c2VkIGluIGFueSBzeXN0ZW0NCj4gCSAgIHRoYXQgcmVxdWlyZXMgSVB2NCBhZGRy ZXNzZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0DQo+IAkgICBjb21tdW5p Y2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0IHBh Y2tldHMNCj4gCSAgICJvbiB0aGUgd2lyZSIuDQo+IAk9PT09DQo+IA0KPiBCdXQgUkZDNzMzNSBz YXlzIChpbiBzZWN0aW9uIDQpOg0KPiANCj4gICBJQU5BIGhhcyBkZWZpbmVkIGEgd2VsbC1rbm93 biByYW5nZSwgMTkyLjAuMC4wLzI5LCBpbiBbUkZDNjMzM10sDQo+ICAgd2hpY2ggaXMgZGVkaWNh dGVkIGZvciBEUy1MaXRlLiAgQXMgZGVmaW5lZCBpbiBbUkZDNjMzM10sIHRoaXMgc3VibmV0DQo+ ICAgaXMgb25seSBwcmVzZW50IGJldHdlZW4gdGhlIEI0IGFuZCB0aGUgQWRkcmVzcyBGYW1pbHkg VHJhbnNpdGlvbg0KPiAgIFJvdXRlciAoQUZUUikgYW5kIG5ldmVyIGVtaXRzIHBhY2tldHMgZnJv bSB0aGlzIHByZWZpeCAib24gdGhlIHdpcmUiLiAgPC0tLQ0KPiAgIDQ2NFhMQVQgaGFzIHRoZSBz YW1lIG5lZWQgZm9yIGEgbm9uLXJvdXRlZCBJUHY0IHByZWZpeCwgYW5kIHRoaXMgc2FtZQ0KPiAg IG5lZWQgbWF5IGJlIGNvbW1vbiBmb3Igb3RoZXIgc2ltaWxhciBzb2x1dGlvbnMuICBJdCBpcyBt b3N0IHBydWRlbnQNCj4gICBhbmQgZWZmZWN0aXZlIHRvIGdlbmVyYWxpemUgMTkyLjAuMC4wLzI5 IGZvciB0aGUgdXNlIG9mIHN1cHBvcnRpbmcNCj4gICBJUHY0IGludGVyZmFjZXMgaW4gSVB2NiB0 cmFuc2l0aW9uIHRlY2hub2xvZ2llcyByYXRoZXIgdGhhbiByZXNlcnZpbmcNCj4gICBhIHByZWZp eCBmb3IgZXZlcnkgcG9zc2libGUgc29sdXRpb24uDQo+IA0KPiBTbywgdGhpcyBhZGRyZXNzIGlz IG9ubHkgdXNlZCAib24gdGhlIGhvc3QiIChub3Qgb24gdGhlIHdpcmUpLCBzbyB3aHkgd291bGQg dGhlcmUgYmUgYW55IG5lZWQgZm9yIHRoZSBESENQIHNlcnZlciB0byBhc3NpZ24gdGhpcyBhZGRy ZXNzPw0KPiANCj4gQW5kIGFzIHRoZSBJUHY2LW9ubHkgb3B0aW9uIG1lYW5zIHRoYXQgdGhlIGhv c3QgbmV2ZXIgY29tcGxldGVzIHRoZSBESENQRElTQ09WRVIvT0ZGRVIvUkVRVUVTVC9BQ0sgKHN0 b3BzIGF0IE9GRkVSKSwgdGhpcyB3b3JrIGNvdWxkIG5vdCBiZSB1c2VkIHRvIGFzc2lnbiBhbnkg YWRkcmVzcy4NCj4gDQo+IC0gQmVybmllDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBkaGN3ZyA8ZGhjd2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIA0K PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDEwLCAyMDE5IDU6MzIgQU0NCj4gVG86IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT47 IGRoY3dnQGlldGYub3JnDQo+IENjOiBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+IFN1 YmplY3Q6IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4g ZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPiANCj4gSGkgSmVuLA0KPiANCj4gVGhhbmsg eW91IGZvciBzaGFyaW5nIHRoaXMgdXBkYXRlZCB2ZXJzaW9uLiBCZWxvdyBzb21lIHBvaW50cyB0 aGF0IEkgZG8gdGhpbmsgbmVlZCBtb3JlIGNsYXJpZmljYXRpb24gaW4gdGhlIEktRDogDQo+IA0K PiAoMSkgVGhlIGRvY3VtZW50IGlzIHRvbyBOQVQ2NCBjZW50cmljLiBUaGUgcHJvcG9zYWwgbWF5 IGFwcGx5IGFzIHdlbGwgZm9yIG90aGVyIElQdjYtb25seSBkZXBsb3ltZW50IHNjZW5hcmlvcyAo dHlwaWNhbGx5LCB1bm1hbmFnZWQgSVB2Ni1vbmx5IENQRXMgd2l0aCBJUHY0YWFTKS4NCj4gDQo+ ICgyKSBBIGRpc2N1c3Npb24gb24gdGhlIGJlbmVmaXQgb2YgdGhpcyBleHRyYSBzaWduYWwgY29t cGFyZWQgdG8gcmVseWluZyBvbiBleGlzdGluZyBzaWduYWxzIChwcmVmNjQsIGFmdHJfbmFtZSwg bWFwX2NvbnRhaW5lci4uLikuIEZvciBleGFtcGxlLCBhIGhvc3QgdGhhdCBzdXBwb3J0cyB0aGUg b3B0aW9uIGlzIHJlYWR5IHRvIHdhaXQgYXQgbWluaW11bSAzMDBzIGFuZCBkaXNhYmxlIGl0cyBJ UHY0IGNvbmZpZ3VyYXRpb24gcmVnYXJkbGVzcyBvZiB3aGF0IGlzIGhhcHBlbmluZyBvbiB0aGUg SVB2NiBsZWcuIEhvdyBpcyB0aGF0IHN1cGVyaW9yIHRvIGEgaG9zdCBkZWxheWluZyBESENQIHBy b2Nlc3MgYnkgeHh4IG1zIHNob3VsZCBiZSBleHBsYWluZWQgZnVydGhlci4gIA0KPiANCj4gKDMp IEhvdyAiSVB2Ni1vbmx5IHByZWZlcnJlZCIgbW9kZSBpcyBzdXBwb3NlZCB0byBiZSBzZXQgYXQg dGhlIGhvc3Qgc2lkZToNCj4gDQo+ID09DQo+ICAgQSBESENQIGNsaWVudCBTSE9VTEQgYWxsb3cg YSBkZXZpY2UgYWRtaW5pc3RyYXRvciB0byBjb25maWd1cmUNCj4gICBJUHY2LW9ubHkgcHJlZmVy cmVkIG1vZGUgZWl0aGVyIGZvciBhIHNwZWNpZmljIGludGVyZmFjZSAodG8gaW5kaWNhdGUNCj4g ICB0aGF0IHRoZSBkZXZpY2UgaXMgSVB2Ni1vbmx5IGNhcGFibGUgaWYgY29ubmVjdGVkIHRvIGEg TkFUNjQgbmV0d29yaw0KPiAgIHZpYSB0aGF0IGludGVyZmFjZSkgb3IgZm9yIGFsbCBpbnRlcmZh Y2VzLiAgDQo+ID09DQo+IA0KPiAqIEkgZ3Vlc3MgdGhlIGRlZmF1bHQgdmFsdWUgd2hlbiB0aGUg b3B0aW9uIGlzIHN1cHBvcnRlZCBieSBhIGhvc3QgaXMgdG8gZGlzYWJsZSBpbmNsdWRpbmcgaXQg aW4gdGhlIHJlcXVlc3QuIFRoZSBkb2N1bWVudCBzaG91bGQgaW5jbHVkZSBhIGRpc2N1c3Npb24g b24gdGhlIGRlZmF1bHQgYmVoYXZpb3IuIA0KPiAqIElmIGFuIGV4cGxpY2l0IGFjdGlvbiBpcyBu ZWVkZWQgZnJvbSB0aGUgdXNlciB0byBlbmFibGUgaW5jbHVkaW5nIHRoZSBvcHRpb24sIGhhdmlu ZyBhIGRpc2N1c3Npb24gdG8gd2hhdCBleHRlbnQgdGhlIGZlYXR1cmUgaXMgbGlrZWx5IHRvIGJl IGVuYWJsZWQgd291bGQgYmUgbmVlZGVkLg0KPiANCj4gKDQpIFRoZSBkb2N1bWVudCBpcyBzdGls bCBtaXhpbmcgdGhlIERIQ1AgY2xpZW50IHZzLiBob3N0IGJlaGF2aW9ycy4gDQo+IEZvciBleGFt cGxlLA0KPiANCj4gICBDbGllbnRzIG5vdCBjYXBhYmxlIG9mIG9wZXJhdGluZyBpbiBhbiBJUHY2 LW9ubHkgTkFUNjQgZW52aXJvbm1lbnQNCj4gICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gICBNVVNUIE5PVCBpbmNsdWRlIHRoZSBJUHY2LW9ubHkg UHJlZmVycmVkIG9wdGlvbiBpbiB0aGUgUGFyYW1ldGVyDQo+ICAgUmVxdWVzdCBMaXN0IG9mIGFu eSBESENQIHBhY2tldHMgYW5kIE1VU1QgaWdub3JlIHRoYXQgb3B0aW9uIGluDQo+ICAgcGFja2V0 cyByZWNlaXZlZCBmcm9tIERIQ1Agc2VydmVycy4NCj4gDQo+IGRvZXMgbm90IG1ha2Ugc2Vuc2Ug Zm9yIGEgREhDUCBjbGllbnQuIA0KPiANCj4gQWxzbywgaG93IHRoZSBob3N0IGlzIGFibGUgdG8g YXNzZXNzL2RldGVybWluZSB0aGF0IGl0IGlzIChub3QpIGNhcGFibGUgdG8gYmVoYXZlIGluIHRo ZSBJUHY2IG1vZGU/IA0KPiANCj4gKDUpIFRoZSBkZWZpbml0aW9uIG9mIElQdjRhYVMgaXMgbm90 IGFsaWduZWQgd2l0aCBvdGhlciBSRkNzOiBlLmcuLCBSRkM4NTg1IHNheXMgdGhlIGZvbGxvd2lu ZzogDQo+IA0KPiAgICJJUHY0YWFTIiBzdGFuZHMgZm9yICJJUHY0LWFzLWEtU2VydmljZSIsIG1l YW5pbmcgdHJhbnNpdGlvbg0KPiAgIHRlY2hub2xvZ2llcyBmb3IgZGVsaXZlcmluZyBJUHY0IGlu IElQdjYtb25seSBjb25uZWN0aXZpdHkuDQo+IA0KPiBXaGlsZSB5b3VycyBpczogDQo+IA0KPiAg IElQdjQtYXMtYS1TZXJ2aWNlOiBhIGRlcGxveW1lbnQgc2NlbmFyaW8gd2hlbiBlbmQgaG9zdHMg YXJlIGV4cGVjdGVkDQo+ICAgdG8gb3BlcmF0ZSBpbiBJUHY2LW9ubHkgbW9kZSBieSBkZWZhdWx0 IGFuZCBJUHY0IGFkZHJlc3NlcyBjYW4gYmUNCj4gICBhc3NpZ25lZCB0byBzb21lIGhvc3RzIGlm IHRob3NlIGhvc3RzIGV4cGxpY2l0bHkgb3B0LWluIHRvIHJlY2VpdmluZw0KPiAgIElQdjQgYWRk cmVzc2VzLg0KPiANCj4gKDYpIERvIHlvdSBjb25zaWRlciBhIGhvc3Qgd2l0aCBDTEFUIGZ1bmN0 aW9uIGFzIGFuIElQdjYtb25seSBob3N0Pw0KPiANCj4gSWYgc28sIHRoZSBmb2xsb3dpbmcgZGVm aW5pdGlvbiBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZlciB0byAiSVB2NCBjb25uZWN0aXZpdHki IHJhdGhlciB0aGFuICJJUHY0IiBpbiBnZW5lcmFsLiBUaGlzIGlzIGJlY2F1c2UgYW4gSVB2NCBh ZGRyZXNzIGlzIHJlcXVpcmVkIGZvciBDTEFUIGZvciBleGFtcGxlLg0KPiANCj4gPT0NCj4gICBJ UHY2LW9ubHkgY2FwYWJsZSBob3N0OiBhIGhvc3Qgd2hpY2ggZG9lcyBub3QgcmVxdWlyZSBJUHY0 IGFuZCBjYW4NCj4gICBvcGVyYXRlIG9uIElQdjYtb25seSBuZXR3b3Jrcy4NCj4gPT0NCj4gDQo+ ICg3KSBXb3VsZG4ndCB0aGUgZm9sbG93aW5nIGFkZCBhbiBleHRyYSBkZWxheSBmb3IgYXBwbGlj YXRpb25zIHJlcXVpcmluZyBDTEFUPw0KPiANCj4gPT0NCj4gVGhlIGhvc3QgTUFZIGRpc2FibGUg SVB2NCBzdGFjaw0KPiAgIGNvbXBsZXRlbHkgZm9yIFY2T05MWV9XQUlUIHNlY29uZHMgb3IgdW50 aWwgdGhlIG5ldHdvcmsgZGlzY29ubmVjdGlvbg0KPiAgIGV2ZW50IGhhcHBlbnMuDQo+ID09DQo+ IA0KPiAoOCkgQ29uc2lkZXIgcmV0dXJuaW5nIGFuIGFkZHJlc3MgZnJvbSB0aGUgcmFuZ2UgZGVm aW5lZCBpbiBSRkM3MzM1IGZvciBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMg YXJlIHJlcXVpcmVkIGFueXdheSBmb3Igc29tZSBJUHY2LW9ubHkgaG9zdHMgKHRob3NlIHdpdGgg YSBDTEFUIGZvciBleGFtcGxlKS4NCj4gDQo+ID09PT0NCj4gICBUaGUgcmVzdWx0IGlzIHRoYXQg MTkyLjAuMC4wLzI5IG1heSBiZSB1c2VkIGluIGFueSBzeXN0ZW0NCj4gICB0aGF0IHJlcXVpcmVz IElQdjQgYWRkcmVzc2VzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggSVB2NA0KPiAg IGNvbW11bmljYXRpb25zIGluIGFuIElQdjYtb25seSBuZXR3b3JrIGJ1dCBkb2VzIG5vdCBlbWl0 IElQdjQgcGFja2V0cw0KPiAgICJvbiB0aGUgd2lyZSIuDQo+ID09PT0NCj4gDQo+IENoZWVycywN Cj4gTWVkDQo+IA0KPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IGRoY3dn IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKZW4gTGlua292 YSANCj4+IEVudm95w6kgOiBtYXJkaSAxMCBkw6ljZW1icmUgMjAxOSAwMTowMiDDgCA6IGRoY3dn QGlldGYub3JnIENjIDogVjYgT3BzIA0KPj4gTGlzdCBPYmpldCA6IFtkaGN3Z10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiBkcmFmdC1saW5rLWRoYy12Nm9ubHktIDAxLnR4 dA0KPj4gDQo+PiBIZWxsbywNCj4+IA0KPj4gVGhhbmtzIHRvIGV2ZXJ5b25lIGZvciB2ZXJ5IHBy b2R1Y3RpdmUgY2VudGktdGhyZWFkIG9uDQo+PiBkcmFmdC1saW5rLWRoYy12Nm9ubHktMDAgOykN Cj4+IEhlcmUgaXMgdGhlIGltcHJvdmVkIHZlcnNpb24sIC0wMS4NCj4+IA0KPj4gVGhlIG1haW4g Y2hhbmdlczoNCj4+IA0KPj4gLSBUaGUgb3B0aW9uIGlzIG5vdCB6ZXJvIGxlbmd0aCBhbnltb3Jl LiBJdCBoYXMgNC1ieXRlcyB2YWx1ZSB3aGljaCANCj4+IG1pZ2h0IGNvbnRhaW4gVjZPTkxZX1dB SVQgdGltZXIuIEJlbmVmaXRzOg0KPj4gICAgLS0tIGFsbG93cyB0aGUgbmV0d29yayBhZG1pbmlz dHJhdG9ycyB0byBwaWxvdCB0aGUgY2hhbmdlcyBhbmQgDQo+PiByb2xsYmFjayBxdWlja2x5IGlm IG5lZWRlZDsNCj4+ICAgIC0tLSBhZGRyZXNzZWQgc29tZSBjb25jZXJuIGFib3V0IGFuIG9wdGlv biBoYXZpbmcgemVybyBsZW5ndGggDQo+PiAoYWxsZWdlZGx5IGl0IG1pZ2h0IGNvbmZ1c2Ugc29t ZSBjbGllbnRzKQ0KPj4gDQo+PiAtIFVzaW5nIGEgZGVkaWNhdGVkIGFkZHJlc3MgdG8gcmV0dXJu IHRvIGNsaWVudHMgaXMgbm93IGFuIG9wdGlvbmFsIA0KPj4gb3B0aW1pc2F0aW9uLiBCeSBkZWZh dWx0IHRoZSBzZXJ2ZXIgaXMgZXhwZWN0ZWQganVzdCB0byByZXR1cm4gYSANCj4+IHJhbmRvbSBh ZGRyZXNzIChhcyB1c3VhbCkuDQo+PiANCj4+IC0gVHlwb3MgZml4ZWQgKHByb2JhYmx5IHNvbWUg bmV3IHR5cG9zIGFkZGVkIHRob3VnaCkuDQo+PiANCj4+IFRoZSBhdXRob3JzIHdvdWxkIGxpa2Ug dGhlIERIQyBXRyB0byBjb25zaWRlciBhZG9wdGluZyB0aGlzIGRvY3VtZW50Lg0KPj4gDQo+PiBU aGFuayB5b3UhDQo+PiANCj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t DQo+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPj4gRGF0ZTogVHVlLCBEZWMg MTAsIDIwMTkgYXQgMTA6NDQgQU0NCj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPj4gVG86IFRvbWVrIE1ydWdhbHNr aSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+LCBMb3JlbnpvIENvbGl0dGkgDQo+PiA8bG9y ZW56b0Bnb29nbGUuY29tPiwgSmVuIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5jb20+LCBNaWNoYWVs IEMuDQo+PiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQo+PiANCj4+IA0KPj4g DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dCBo YXMgYmVlbiANCj4+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmVuIExpbmtvdmEgYW5kIHBv c3RlZCB0byB0aGUgSUVURiANCj4+IHJlcG9zaXRvcnkuDQo+PiANCj4+IE5hbWU6ICAgICAgICAg ICBkcmFmdC1saW5rLWRoYy12Nm9ubHkNCj4+IFJldmlzaW9uOiAgICAgICAwMQ0KPj4gVGl0bGU6 ICAgICAgICAgIElQdjYtT25seS1QcmVmZXJyZWQgT3B0aW9uIGZvciBESENQDQo+PiBEb2N1bWVu dCBkYXRlOiAgMjAxOS0xMi0wOQ0KPj4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPj4gUGFnZXM6ICAgICAgICAgIDEwDQo+PiBVUkw6DQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpbmst ZGhjLXY2b25seS8NCj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxDQo+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9ubHkNCj4+IERp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGlu ay1kaGMtdjZvbmx5LTAxDQo+PiANCj4+IEFic3RyYWN0Og0KPj4gICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyBhIERIQ1Agb3B0aW9uIHRvIGluZGljYXRlIHRoYXQgYSBob3N0DQo+PiAgIHN1cHBv cnRzIGFuIElQdjYtb25seSBtb2RlIGFuZCB3aWxsaW5nIHRvIGZvcmdvIG9idGFpbmluZyBhbiBJ UHY0DQo+PiAgIGFkZHJlc3MgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXMgSVB2NiBjb25uZWN0aXZp dHkuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IA0KPj4gdG9v bHMuaWV0Zi5vcmcuDQo+PiANCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiANCj4+IA0KPj4g LS0NCj4+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4+IA0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRoY3dnIG1haWxpbmcgbGlzdA0K Pj4gZGhjd2dAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGhjd2cNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiBkaGN3Z0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KDQo= From nobody Tue Dec 10 09:09:40 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A56120927 for ; Tue, 10 Dec 2019 09:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuPteAfgx3WG for ; Tue, 10 Dec 2019 09:09:38 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A80120924 for ; Tue, 10 Dec 2019 09:09:38 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id k25so9189045pgt.7 for ; Tue, 10 Dec 2019 09:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZMahLyCRo+UA/8M0yeBiuXHLzUr+dnM9/HlPXY2vUvE=; b=nRHWfdkNwn87/c22QG37P9smRgpll7klqWOIGQaOJAsRSWtJsPWs05LZazxJthRmQy lRAEIY01nRtvKrehftXGzJECTe6P+mE8ainIoUpdErs9Uyg+r7h8hV4AEMOqr+htNPW2 2J6wHmJluCf+Jieq1JStazIFF33W9P9MoCf3yKJuFTcAZfGFdnWEgux2lqzI+8HCf2yt c90L4/8QL+XTV3kCiHQcmyEr7IScvWI5W3MdVZvmCbTx+F5iDHNKmubcRm1APsq/qsJH f7N8ZqO8UkyudyjFqpBtg8eL84o4Hu33oBXaSwnj1Gt2J4GB/J7ZcKhl5pM9RT+o0d7H nRtg== 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=ZMahLyCRo+UA/8M0yeBiuXHLzUr+dnM9/HlPXY2vUvE=; b=A7v4xoGKQaWobDfzkLwsonH9YCGUKmtpBDCnYNuTh8tj5tIdWceqxtkheCyFewJzE1 NwvBn2qCl8TtRTzzNrazwkxm6wbor87aS5je4YSyIcOX/Xra62mJHjcc5X/wy8TyLSfy ax6A3wcEvBY8vOT+mAyLJDys5iSJT1AQenTjJzyRq4EIwcpy/4lf5L/qS2920mln47GM oYwXZOPc1eR2wWHFY7AKoUQWJAPfAAkY6iWWHK/RhvCUU/D2Ui0Id+GN7iynJmA9Rjij IZVBGkoTu1Ys1cqs2nXX6Oc/uiS+nvGTVYtQQ3IU1bcEOvtc2s+9SYsKdJ67OM0beggg o7rg== X-Gm-Message-State: APjAAAVfl++vRrNIxZZ1/e1iQU2Fcbba7+L+Bi1Db9+6MN4MJtLpOLBC OA9mgxfjNmcerAr8nefwMsJ/lg== X-Google-Smtp-Source: APXvYqxbh6D/gw6UmcOnkaM6P+KFZaQdaDdXmCAUNhI9sy7XcwcjIjJbZ0N7z9hKiw/HT4R15Aj6yQ== X-Received: by 2002:aa7:9d0d:: with SMTP id k13mr30486758pfp.254.1575997777722; Tue, 10 Dec 2019 09:09:37 -0800 (PST) Received: from [17.192.139.178] ([17.192.139.178]) by smtp.gmail.com with ESMTPSA id y38sm3961618pgk.33.2019.12.10.09.09.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 09:09:36 -0800 (PST) From: Ted Lemon Message-Id: <6974A6C2-5731-47F6-9E4D-C33B90EFD7E1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D1863FA5-0CF3-47DB-BF5F-815111B6AD0B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Tue, 10 Dec 2019 09:09:35 -0800 In-Reply-To: Cc: "mohamed.boucadair@orange.com" , Jen Linkova , "dhcwg@ietf.org" , V6 Ops List To: "Bernie Volz (volz)" References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 17:09:40 -0000 --Apple-Mail=_D1863FA5-0CF3-47DB-BF5F-815111B6AD0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 10, 2019, at 8:53 AM, Bernie Volz (volz) wrote: > I've debated that issue on end and not going to do it any further. I = completely disagree - server should return whatever it would have = returned if the option is were not present. How about =E2=80=9Cserver SHOULD return 0.0.0.0; server MAY return some = other bogus address, which the client MUST ignore=E2=80=9D? The reason = I=E2=80=99m hassling you about this is that you have a very specific = solution in mind, and it=E2=80=99s not a long-term solution. I don=E2=80= =99t mind accommodating your solution, but I don=E2=80=99t want to be = married to it for the rest of eternity. --Apple-Mail=_D1863FA5-0CF3-47DB-BF5F-815111B6AD0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 10, 2019, at 8:53 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
I've debated = that issue on end and not going to do it any further. I completely = disagree - server should return whatever it would have returned if the = option is were not present.

How about =E2=80=9Cserver SHOULD return = 0.0.0.0; server MAY return some other bogus address, which the client = MUST ignore=E2=80=9D?   The reason I=E2=80=99m hassling you about = this is that you have a very specific solution in mind, and it=E2=80=99s = not a long-term solution.   I don=E2=80=99t mind accommodating your = solution, but I don=E2=80=99t want to be married to it for the rest of = eternity.

= --Apple-Mail=_D1863FA5-0CF3-47DB-BF5F-815111B6AD0B-- From nobody Tue Dec 10 09:16:56 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318A120905; Tue, 10 Dec 2019 09:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 PHmxwJlhr5Jf; Tue, 10 Dec 2019 09:16:47 -0800 (PST) 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 C061A120100; Tue, 10 Dec 2019 09:16:47 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBAHFHfo010619; Tue, 10 Dec 2019 12:16:46 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2wtf6jgu9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 12:16:45 -0500 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 xBAHGhHg024664; Tue, 10 Dec 2019 12:16:44 -0500 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 xBAHGXnD024296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Dec 2019 12:16:33 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id E82914009E84; Tue, 10 Dec 2019 17:16:33 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30484.vci.att.com (Service) with ESMTPS id C303F4009E7D; Tue, 10 Dec 2019 17:16:33 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 12:16:33 -0500 From: "STARK, BARBARA H" To: "'Ted Lemon'" , "'Bernie Volz (volz)'" CC: "'dhcwg@ietf.org'" , "'V6 Ops List'" Thread-Topic: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3hrvkTFCkrF9EyvHpagg10RDKezlNZQ Date: Tue, 10 Dec 2019 17:16:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153707127@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.71.224] 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:6.0.95,18.0.572 definitions=2019-12-10_05:2019-12-10,2019-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 spamscore=0 priorityscore=1501 suspectscore=0 impostorscore=0 mlxscore=0 clxscore=1015 bulkscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912100148 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 17:16:50 -0000 PiBGcm9tOiBUZWQgTGVtb24NCj4gDQo+IEkgcmVhbGx5IHRoaW5rIHlvdSBzaG91bGQgaGF2ZSBh IGNsZWFyIGp1c3RpZmljYXRpb24gZm9yIGRvaW5nIGFueXRoaW5nIG90aGVyDQo+IHRoYW4gcmV0 dXJuaW5nIDAuMC4wLjAuICAgQW55dGhpbmcgZWxzZSBpcyBnb2luZyB0byBiZSBtb3JlIGNvbXBs aWNhdGVkIGluIHRoZQ0KPiBsb25nIHRlcm0uICAgVGhlIGp1c3RpZmljYXRpb24g4oCcYmVjYXVz ZSAwLjAuMC4wIHdvdWxkIGJlIGZpbHRlcmVkIG91dCBieSB0aGUNCj4gc2VydmVy4oCdIHNlZW1z IGxpa2UgaXTigJlzIHZlcnkgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50IGFuZCBub3QgcmVhbGx5 IHRoYXQNCj4gYmlnIGEgZGVhbC4gICBJcyB0aGF0IHlvdXIgb25seSByZWFzb24/DQoNClNvbWUg Q0Ugcm91dGVycyBhcmUgY29kZWQgdG8gaGF2ZSBzcGVjaWFsIGhhbmRsaW5nIGZvciAwLjAuMC4w LiBNdWx0aXBsZSBJU1BzIHVzZSB0aGF0IGFkZHJlc3MgZm9yIElQVFYgbXVsdGljYXN0IHRyYWZm aWMgKG9uIGEgVkxBTiBkZWRpY2F0ZWQgdG8gdGhhdCB0cmFmZmljKS4gSSBjb3VsZCBlbnZpc2lv biBzdWNoIHJvdXRlcnMgaGF2aW5nIGlzc3VlcyB3aXRoIGdldHRpbmcgMC4wLjAuMCBmcm9tIERI Q1B2NC4gQ0Ugcm91dGVyIHZlbmRvcnMgYW5kIHRoZWlyIGNoaXBzZXQgdmVuZG9ycyBkbyB0aGUg ZGFybmVkZXN0IHRoaW5ncyBzb21ldGltZXMgKGFzIENsb3VkZmxhcmUgZGlzY292ZXJlZCB3cnQg MS4xLjEuMSkuICBJIHRoaW5rIHdpZGVzcHJlYWQgdGVzdGluZyBvZiBDRSByb3V0ZXJzIGlzIG5l ZWRlZCBpZiB0aGUgcmV0dXJuZWQgYWRkcmVzcyBpcyBnb2luZyB0byBiZSByZXF1aXJlZCB0byAw LjAuMC4wLiANCg0KSGVyZSBpcyBsYW5ndWFnZSBmcm9tIEJCRiBUUi0xMjQgKHJlcXVpcmVtZW50 IExBTi5JR01QLlJPVVRFRCk6ICJJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSBhIFdB Ti1mYWNpbmcgSVB2NCBpbnRlcmZhY2Ugd2l0aCBhbiBJUG9FIGVuY2Fwc3VsYXRpb24gYW5kIG5v IElQdjQgYWRkcmVzcyB2aXNpYmxlIGJ5IHRoZSBhY2Nlc3MgbmV0d29yay4gSXQgTVVTVCBiZSBw b3NzaWJsZSB0byByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIG9uIHN1Y2ggYW4gaW50ZXJmYWNl LCBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHVwc3RyZWFtIElHTVAgaXMgc2VudCBvbiB0aGlzIGlu dGVyZmFjZSBvciBub3QuIFRoZSBSRydzIElHTVAgcHJveHktcm91dGluZyBmdW5jdGlvbiBNVVNU IGJlIGFibGUgdG8gc2VuZCB1cHN0cmVhbSBJR01QIHRyYWZmaWMgb24gc3VjaCBhbiBpbnRlcmZh Y2UsIHVzaW5nIGFuIHVuc3BlY2lmaWVkICgwLjAuMC4wLzo6KSBJUHY0IHNvdXJjZSBhZGRyZXNz LiINCg0KSSdtIGxlYW5pbmcgdG93YXJkIG5vdCBvdmVyLXNwZWNpZnlpbmcgd2hhdCBhZGRyZXNz IGdldHMgcmV0dXJuZWQuDQpCYXJiYXJhDQoNCj4gPiBPbiBEZWMgMTAsIDIwMTksIGF0IDg6MTEg QU0sIEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4g SGk6DQo+ID4NCj4gPiBJcyAoOCk6DQo+ID4NCj4gPiAJKDgpIENvbnNpZGVyIHJldHVybmluZyBh biBhZGRyZXNzIGZyb20gdGhlIHJhbmdlIGRlZmluZWQgaW4gUkZDNzMzNQ0KPiBmb3IgSVB2Ni1v bmx5IGhvc3RzLiBTdWNoIElQdjQgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCBhbnl3YXkgZm9yIHNv bWUgSVB2Ni0NCj4gb25seSBob3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0K PiA+DQo+ID4gCT09PT0NCj4gPiAJICAgVGhlIHJlc3VsdCBpcyB0aGF0IDE5Mi4wLjAuMC8yOSBt YXkgYmUgdXNlZCBpbiBhbnkgc3lzdGVtDQo+ID4gCSAgIHRoYXQgcmVxdWlyZXMgSVB2NCBhZGRy ZXNzZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0DQo+ID4gCSAgIGNvbW11 bmljYXRpb25zIGluIGFuIElQdjYtb25seSBuZXR3b3JrIGJ1dCBkb2VzIG5vdCBlbWl0IElQdjQN Cj4gcGFja2V0cw0KPiA+IAkgICAib24gdGhlIHdpcmUiLg0KPiA+IAk9PT09DQo+ID4NCj4gPiBC dXQgUkZDNzMzNSBzYXlzIChpbiBzZWN0aW9uIDQpOg0KPiA+DQo+ID4gICBJQU5BIGhhcyBkZWZp bmVkIGEgd2VsbC1rbm93biByYW5nZSwgMTkyLjAuMC4wLzI5LCBpbiBbUkZDNjMzM10sDQo+ID4g ICB3aGljaCBpcyBkZWRpY2F0ZWQgZm9yIERTLUxpdGUuICBBcyBkZWZpbmVkIGluIFtSRkM2MzMz XSwgdGhpcyBzdWJuZXQNCj4gPiAgIGlzIG9ubHkgcHJlc2VudCBiZXR3ZWVuIHRoZSBCNCBhbmQg dGhlIEFkZHJlc3MgRmFtaWx5IFRyYW5zaXRpb24NCj4gPiAgIFJvdXRlciAoQUZUUikgYW5kIG5l dmVyIGVtaXRzIHBhY2tldHMgZnJvbSB0aGlzIHByZWZpeCAib24gdGhlIHdpcmUiLiAgPC0tLQ0K PiA+ICAgNDY0WExBVCBoYXMgdGhlIHNhbWUgbmVlZCBmb3IgYSBub24tcm91dGVkIElQdjQgcHJl Zml4LCBhbmQgdGhpcyBzYW1lDQo+ID4gICBuZWVkIG1heSBiZSBjb21tb24gZm9yIG90aGVyIHNp bWlsYXIgc29sdXRpb25zLiAgSXQgaXMgbW9zdCBwcnVkZW50DQo+ID4gICBhbmQgZWZmZWN0aXZl IHRvIGdlbmVyYWxpemUgMTkyLjAuMC4wLzI5IGZvciB0aGUgdXNlIG9mIHN1cHBvcnRpbmcNCj4g PiAgIElQdjQgaW50ZXJmYWNlcyBpbiBJUHY2IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIHJhdGhl ciB0aGFuIHJlc2VydmluZw0KPiA+ICAgYSBwcmVmaXggZm9yIGV2ZXJ5IHBvc3NpYmxlIHNvbHV0 aW9uLg0KPiA+DQo+ID4gU28sIHRoaXMgYWRkcmVzcyBpcyBvbmx5IHVzZWQgIm9uIHRoZSBob3N0 IiAobm90IG9uIHRoZSB3aXJlKSwgc28gd2h5IHdvdWxkDQo+IHRoZXJlIGJlIGFueSBuZWVkIGZv ciB0aGUgREhDUCBzZXJ2ZXIgdG8gYXNzaWduIHRoaXMgYWRkcmVzcz8NCj4gPg0KPiA+IEFuZCBh cyB0aGUgSVB2Ni1vbmx5IG9wdGlvbiBtZWFucyB0aGF0IHRoZSBob3N0IG5ldmVyIGNvbXBsZXRl cyB0aGUNCj4gREhDUERJU0NPVkVSL09GRkVSL1JFUVVFU1QvQUNLIChzdG9wcyBhdCBPRkZFUiks IHRoaXMgd29yayBjb3VsZCBub3QNCj4gYmUgdXNlZCB0byBhc3NpZ24gYW55IGFkZHJlc3MuDQo+ ID4NCj4gPiAtIEJlcm5pZQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiBGcm9tOiBkaGN3ZyA8ZGhjd2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4g bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDEwLCAyMDE5IDU6MzIgQU0NCj4gPiBUbzogSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29t PjsgZGhjd2dAaWV0Zi5vcmcNCj4gPiBDYzogVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPg0K PiA+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cg0KPiA+IGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50eHQNCj4gPg0KPiA+IEhpIEplbiwNCj4g Pg0KPiA+IFRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGlzIHVwZGF0ZWQgdmVyc2lvbi4gQmVsb3cg c29tZSBwb2ludHMgdGhhdCBJIGRvDQo+IHRoaW5rIG5lZWQgbW9yZSBjbGFyaWZpY2F0aW9uIGlu IHRoZSBJLUQ6DQo+ID4NCj4gPiAoMSkgVGhlIGRvY3VtZW50IGlzIHRvbyBOQVQ2NCBjZW50cmlj LiBUaGUgcHJvcG9zYWwgbWF5IGFwcGx5IGFzIHdlbGwgZm9yDQo+IG90aGVyIElQdjYtb25seSBk ZXBsb3ltZW50IHNjZW5hcmlvcyAodHlwaWNhbGx5LCB1bm1hbmFnZWQgSVB2Ni1vbmx5IENQRXMN Cj4gd2l0aCBJUHY0YWFTKS4NCj4gPg0KPiA+ICgyKSBBIGRpc2N1c3Npb24gb24gdGhlIGJlbmVm aXQgb2YgdGhpcyBleHRyYSBzaWduYWwgY29tcGFyZWQgdG8gcmVseWluZyBvbg0KPiBleGlzdGlu ZyBzaWduYWxzIChwcmVmNjQsIGFmdHJfbmFtZSwgbWFwX2NvbnRhaW5lci4uLikuIEZvciBleGFt cGxlLCBhIGhvc3QNCj4gdGhhdCBzdXBwb3J0cyB0aGUgb3B0aW9uIGlzIHJlYWR5IHRvIHdhaXQg YXQgbWluaW11bSAzMDBzIGFuZCBkaXNhYmxlIGl0cyBJUHY0DQo+IGNvbmZpZ3VyYXRpb24gcmVn YXJkbGVzcyBvZiB3aGF0IGlzIGhhcHBlbmluZyBvbiB0aGUgSVB2NiBsZWcuIEhvdyBpcyB0aGF0 DQo+IHN1cGVyaW9yIHRvIGEgaG9zdCBkZWxheWluZyBESENQIHByb2Nlc3MgYnkgeHh4IG1zIHNo b3VsZCBiZSBleHBsYWluZWQNCj4gZnVydGhlci4NCj4gPg0KPiA+ICgzKSBIb3cgIklQdjYtb25s eSBwcmVmZXJyZWQiIG1vZGUgaXMgc3VwcG9zZWQgdG8gYmUgc2V0IGF0IHRoZSBob3N0IHNpZGU6 DQo+ID4NCj4gPiA9PQ0KPiA+ICAgQSBESENQIGNsaWVudCBTSE9VTEQgYWxsb3cgYSBkZXZpY2Ug YWRtaW5pc3RyYXRvciB0byBjb25maWd1cmUNCj4gPiAgIElQdjYtb25seSBwcmVmZXJyZWQgbW9k ZSBlaXRoZXIgZm9yIGEgc3BlY2lmaWMgaW50ZXJmYWNlICh0byBpbmRpY2F0ZQ0KPiA+ICAgdGhh dCB0aGUgZGV2aWNlIGlzIElQdjYtb25seSBjYXBhYmxlIGlmIGNvbm5lY3RlZCB0byBhIE5BVDY0 IG5ldHdvcmsNCj4gPiAgIHZpYSB0aGF0IGludGVyZmFjZSkgb3IgZm9yIGFsbCBpbnRlcmZhY2Vz Lg0KPiA+ID09DQo+ID4NCj4gPiAqIEkgZ3Vlc3MgdGhlIGRlZmF1bHQgdmFsdWUgd2hlbiB0aGUg b3B0aW9uIGlzIHN1cHBvcnRlZCBieSBhIGhvc3QgaXMgdG8NCj4gZGlzYWJsZSBpbmNsdWRpbmcg aXQgaW4gdGhlIHJlcXVlc3QuIFRoZSBkb2N1bWVudCBzaG91bGQgaW5jbHVkZSBhIGRpc2N1c3Np b24NCj4gb24gdGhlIGRlZmF1bHQgYmVoYXZpb3IuDQo+ID4gKiBJZiBhbiBleHBsaWNpdCBhY3Rp b24gaXMgbmVlZGVkIGZyb20gdGhlIHVzZXIgdG8gZW5hYmxlIGluY2x1ZGluZyB0aGUNCj4gb3B0 aW9uLCBoYXZpbmcgYSBkaXNjdXNzaW9uIHRvIHdoYXQgZXh0ZW50IHRoZSBmZWF0dXJlIGlzIGxp a2VseSB0byBiZSBlbmFibGVkDQo+IHdvdWxkIGJlIG5lZWRlZC4NCj4gPg0KPiA+ICg0KSBUaGUg ZG9jdW1lbnQgaXMgc3RpbGwgbWl4aW5nIHRoZSBESENQIGNsaWVudCB2cy4gaG9zdCBiZWhhdmlv cnMuDQo+ID4gRm9yIGV4YW1wbGUsDQo+ID4NCj4gPiAgIENsaWVudHMgbm90IGNhcGFibGUgb2Yg b3BlcmF0aW5nIGluIGFuIElQdjYtb25seSBOQVQ2NCBlbnZpcm9ubWVudA0KPiA+ICAgXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4gICBNVVNUIE5P VCBpbmNsdWRlIHRoZSBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiBpbiB0aGUgUGFyYW1ldGVy DQo+ID4gICBSZXF1ZXN0IExpc3Qgb2YgYW55IERIQ1AgcGFja2V0cyBhbmQgTVVTVCBpZ25vcmUg dGhhdCBvcHRpb24gaW4NCj4gPiAgIHBhY2tldHMgcmVjZWl2ZWQgZnJvbSBESENQIHNlcnZlcnMu DQo+ID4NCj4gPiBkb2VzIG5vdCBtYWtlIHNlbnNlIGZvciBhIERIQ1AgY2xpZW50Lg0KPiA+DQo+ ID4gQWxzbywgaG93IHRoZSBob3N0IGlzIGFibGUgdG8gYXNzZXNzL2RldGVybWluZSB0aGF0IGl0 IGlzIChub3QpIGNhcGFibGUgdG8NCj4gYmVoYXZlIGluIHRoZSBJUHY2IG1vZGU/DQo+ID4NCj4g PiAoNSkgVGhlIGRlZmluaXRpb24gb2YgSVB2NGFhUyBpcyBub3QgYWxpZ25lZCB3aXRoIG90aGVy IFJGQ3M6IGUuZy4sIFJGQzg1ODUNCj4gc2F5cyB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAi SVB2NGFhUyIgc3RhbmRzIGZvciAiSVB2NC1hcy1hLVNlcnZpY2UiLCBtZWFuaW5nIHRyYW5zaXRp b24NCj4gPiAgIHRlY2hub2xvZ2llcyBmb3IgZGVsaXZlcmluZyBJUHY0IGluIElQdjYtb25seSBj b25uZWN0aXZpdHkuDQo+ID4NCj4gPiBXaGlsZSB5b3VycyBpczoNCj4gPg0KPiA+ICAgSVB2NC1h cy1hLVNlcnZpY2U6IGEgZGVwbG95bWVudCBzY2VuYXJpbyB3aGVuIGVuZCBob3N0cyBhcmUgZXhw ZWN0ZWQNCj4gPiAgIHRvIG9wZXJhdGUgaW4gSVB2Ni1vbmx5IG1vZGUgYnkgZGVmYXVsdCBhbmQg SVB2NCBhZGRyZXNzZXMgY2FuIGJlDQo+ID4gICBhc3NpZ25lZCB0byBzb21lIGhvc3RzIGlmIHRo b3NlIGhvc3RzIGV4cGxpY2l0bHkgb3B0LWluIHRvIHJlY2VpdmluZw0KPiA+ICAgSVB2NCBhZGRy ZXNzZXMuDQo+ID4NCj4gPiAoNikgRG8geW91IGNvbnNpZGVyIGEgaG9zdCB3aXRoIENMQVQgZnVu Y3Rpb24gYXMgYW4gSVB2Ni1vbmx5IGhvc3Q/DQo+ID4NCj4gPiBJZiBzbywgdGhlIGZvbGxvd2lu ZyBkZWZpbml0aW9uIHNob3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyIHRvICJJUHY0DQo+IGNvbm5l Y3Rpdml0eSIgcmF0aGVyIHRoYW4gIklQdjQiIGluIGdlbmVyYWwuIFRoaXMgaXMgYmVjYXVzZSBh biBJUHY0IGFkZHJlc3MgaXMNCj4gcmVxdWlyZWQgZm9yIENMQVQgZm9yIGV4YW1wbGUuDQo+ID4N Cj4gPiA9PQ0KPiA+ICAgSVB2Ni1vbmx5IGNhcGFibGUgaG9zdDogYSBob3N0IHdoaWNoIGRvZXMg bm90IHJlcXVpcmUgSVB2NCBhbmQgY2FuDQo+ID4gICBvcGVyYXRlIG9uIElQdjYtb25seSBuZXR3 b3Jrcy4NCj4gPiA9PQ0KPiA+DQo+ID4gKDcpIFdvdWxkbid0IHRoZSBmb2xsb3dpbmcgYWRkIGFu IGV4dHJhIGRlbGF5IGZvciBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nDQo+IENMQVQ/DQo+ID4NCj4g PiA9PQ0KPiA+IFRoZSBob3N0IE1BWSBkaXNhYmxlIElQdjQgc3RhY2sNCj4gPiAgIGNvbXBsZXRl bHkgZm9yIFY2T05MWV9XQUlUIHNlY29uZHMgb3IgdW50aWwgdGhlIG5ldHdvcmsgZGlzY29ubmVj dGlvbg0KPiA+ICAgZXZlbnQgaGFwcGVucy4NCj4gPiA9PQ0KPiA+DQo+ID4gKDgpIENvbnNpZGVy IHJldHVybmluZyBhbiBhZGRyZXNzIGZyb20gdGhlIHJhbmdlIGRlZmluZWQgaW4gUkZDNzMzNSBm b3INCj4gSVB2Ni1vbmx5IGhvc3RzLiBTdWNoIElQdjQgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCBh bnl3YXkgZm9yIHNvbWUgSVB2Ni1vbmx5DQo+IGhvc3RzICh0aG9zZSB3aXRoIGEgQ0xBVCBmb3Ig ZXhhbXBsZSkuDQo+ID4NCj4gPiA9PT09DQo+ID4gICBUaGUgcmVzdWx0IGlzIHRoYXQgMTkyLjAu MC4wLzI5IG1heSBiZSB1c2VkIGluIGFueSBzeXN0ZW0NCj4gPiAgIHRoYXQgcmVxdWlyZXMgSVB2 NCBhZGRyZXNzZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0DQo+ID4gICBj b21tdW5pY2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJ UHY0IHBhY2tldHMNCj4gPiAgICJvbiB0aGUgd2lyZSIuDQo+ID4gPT09PQ0KPiA+DQo+ID4gQ2hl ZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ PiBEZSA6IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBKZW4gTGlua292YQ0KPiA+PiBFbnZvecOpIDogbWFyZGkgMTAgZMOpY2VtYnJlIDIwMTkgMDE6 MDIgw4AgOiBkaGN3Z0BpZXRmLm9yZyBDYyA6IFY2IE9wcw0KPiA+PiBMaXN0IE9iamV0IDogW2Ro Y3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4gZHJhZnQtbGluay1k aGMtdjZvbmx5LSAwMS50eHQNCj4gPj4NCj4gPj4gSGVsbG8sDQo+ID4+DQo+ID4+IFRoYW5rcyB0 byBldmVyeW9uZSBmb3IgdmVyeSBwcm9kdWN0aXZlIGNlbnRpLXRocmVhZCBvbg0KPiA+PiBkcmFm dC1saW5rLWRoYy12Nm9ubHktMDAgOykNCj4gPj4gSGVyZSBpcyB0aGUgaW1wcm92ZWQgdmVyc2lv biwgLTAxLg0KPiA+Pg0KPiA+PiBUaGUgbWFpbiBjaGFuZ2VzOg0KPiA+Pg0KPiA+PiAtIFRoZSBv cHRpb24gaXMgbm90IHplcm8gbGVuZ3RoIGFueW1vcmUuIEl0IGhhcyA0LWJ5dGVzIHZhbHVlIHdo aWNoDQo+ID4+IG1pZ2h0IGNvbnRhaW4gVjZPTkxZX1dBSVQgdGltZXIuIEJlbmVmaXRzOg0KPiA+ PiAgICAtLS0gYWxsb3dzIHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIHRvIHBpbG90IHRoZSBj aGFuZ2VzIGFuZA0KPiA+PiByb2xsYmFjayBxdWlja2x5IGlmIG5lZWRlZDsNCj4gPj4gICAgLS0t IGFkZHJlc3NlZCBzb21lIGNvbmNlcm4gYWJvdXQgYW4gb3B0aW9uIGhhdmluZyB6ZXJvIGxlbmd0 aA0KPiA+PiAoYWxsZWdlZGx5IGl0IG1pZ2h0IGNvbmZ1c2Ugc29tZSBjbGllbnRzKQ0KPiA+Pg0K PiA+PiAtIFVzaW5nIGEgZGVkaWNhdGVkIGFkZHJlc3MgdG8gcmV0dXJuIHRvIGNsaWVudHMgaXMg bm93IGFuIG9wdGlvbmFsDQo+ID4+IG9wdGltaXNhdGlvbi4gQnkgZGVmYXVsdCB0aGUgc2VydmVy IGlzIGV4cGVjdGVkIGp1c3QgdG8gcmV0dXJuIGENCj4gPj4gcmFuZG9tIGFkZHJlc3MgKGFzIHVz dWFsKS4NCj4gPj4NCj4gPj4gLSBUeXBvcyBmaXhlZCAocHJvYmFibHkgc29tZSBuZXcgdHlwb3Mg YWRkZWQgdGhvdWdoKS4NCj4gPj4NCj4gPj4gVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0aGUgREhD IFdHIHRvIGNvbnNpZGVyIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuDQo+ID4+DQo+ID4+IFRoYW5r IHlvdSENCj4gPj4NCj4gPj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0N Cj4gPj4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPj4gRGF0ZTogVHVlLCBE ZWMgMTAsIDIwMTkgYXQgMTA6NDQgQU0NCj4gPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0DQo+ID4+IFRvOiBUb21layBN cnVnYWxza2kgPHRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPiwgTG9yZW56byBDb2xpdHRpDQo+ ID4+IDxsb3JlbnpvQGdvb2dsZS5jb20+LCBKZW4gTGlua292YSA8ZnVycnlAZ29vZ2xlLmNvbT4s IE1pY2hhZWwgQy4NCj4gPj4gUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGluay1kaGMt djZvbmx5LTAxLnR4dCBoYXMgYmVlbg0KPiA+PiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpl biBMaW5rb3ZhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gPj4gcmVwb3NpdG9yeS4NCj4gPj4N Cj4gPj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhjLXY2b25seQ0KPiA+PiBSZXZpc2lv bjogICAgICAgMDENCj4gPj4gVGl0bGU6ICAgICAgICAgIElQdjYtT25seS1QcmVmZXJyZWQgT3B0 aW9uIGZvciBESENQDQo+ID4+IERvY3VtZW50IGRhdGU6ICAyMDE5LTEyLTA5DQo+ID4+IEdyb3Vw OiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPj4gUGFnZXM6ICAgICAgICAgIDEw DQo+ID4+IFVSTDoNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRzX2RyYWZ0LTJE bGluay0yRGRoYy0yRHY2b25seS0NCj4gMkQwMS50eHQmZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4c2M4U1k4VHE0dnJmb2cmbT0zM2FBZkQtX0ZSMUtSRTBW NnlwR0ZER1FkWC0NCj4gOUtVemlUQTBhT1VQTV9mYyZzPUR6RThrbGx0cGs4MmdKM1h6d1M5QThQ aUhOWVIycTQwMmc4VVdoOFh0MlUNCj4gJmU9DQo+ID4+IFN0YXR1czogICAgICAgICBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJh Y2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRsaW5rLTJEZGhjLQ0KPiAyRHY2b25seV8mZD1Ed0lH YVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4c2M4U1k4VHE0dnJmb2cm bT0zM2FBZkQtX0ZSMUtSRTBWNnlwR0ZER1FkWC0NCj4gOUtVemlUQTBhT1VQTV9mYyZzPUZCanVD cWdfSXh4ZXpuOS0NCj4gdUxXT0xrbFlzb1FJbGRiSFB3TFNucmxRSkZRJmU9DQo+ID4+IEh0bWxp emVkOiAgICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtDQo+IDNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEbGluay0yRGRoYy0yRHY2b25s eS0NCj4gMkQwMSZkPUR3SUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtDQo+ IDhzYzhTWThUcTR2cmZvZyZtPTMzYUFmRC1fRlIxS1JFMFY2eXBHRkRHUWRYLQ0KPiA5S1V6aVRB MGFPVVBNX2ZjJnM9X3QtDQo+IGZDWXR4bE9VOVl4SUJra2I3b3NjQWk2Q1lfMDJ6em4xcXFOT3Vv MFEmZT0NCj4gPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1s X2RyYWZ0LTJEbGluay0yRGRoYy0NCj4gMkR2Nm9ubHkmZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4c2M4U1k4VHE0dnJmb2cmbT0zM2FBZkQtX0ZSMUtSRTBW NnlwR0ZER1FkWC0NCj4gOUtVemlUQTBhT1VQTV9mYyZzPWJKWEpiRDBLMU5PSF9ONG5Hazk2U2Rs dks4UUNGSnlBS0s2Z1UwZFB0cg0KPiBFJmU9DQo+ID4+IERpZmY6ICAgICAgICAgICBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0 Zi5vcmdfcmZjZGlmZi0zRnVybDItM0RkcmFmdC0yRGxpbmstMkRkaGMtMkR2Nm9ubHktDQo+IDJE MDEmZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLQ0KPiA4c2M4U1k4 VHE0dnJmb2cmbT0zM2FBZkQtX0ZSMUtSRTBWNnlwR0ZER1FkWC0NCj4gOUtVemlUQTBhT1VQTV9m YyZzPUlQY3UzMEdtcjJ4MXR3eGNSaDRFbkRlT19vam8wSG1QeER1Wm5POW9JRg0KPiA0JmU9DQo+ ID4+DQo+ID4+IEFic3RyYWN0Og0KPiA+PiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgREhD UCBvcHRpb24gdG8gaW5kaWNhdGUgdGhhdCBhIGhvc3QNCj4gPj4gICBzdXBwb3J0cyBhbiBJUHY2 LW9ubHkgbW9kZSBhbmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4gSVB2NA0KPiA+PiAg IGFkZHJlc3MgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXMgSVB2NiBjb25uZWN0aXZpdHkuDQo+ID4+ DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+PiB0b29s cy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4NCj4gPj4N Cj4gPj4gLS0NCj4gPj4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBkaGN3ZyBt YWlsaW5nIGxpc3QNCj4gPj4gZGhjd2dAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haQ0K PiA+PiBsbWFuX2xpc3RpbmZvX2RoY3dnJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1Fp Y3ZqSWcmcj1Mb0d6aEMtOHNjOFNZDQo+ID4+IDhUcTR2cmZvZyZtPTMzYUFmRC1fRlIxS1JFMFY2 eXBHRkRHUWRYLQ0KPiA5S1V6aVRBMGFPVVBNX2ZjJnM9QXN0cVlkb29XRnkNCj4gPj4gbkxpcWE3 Tl9TY01naGJoaEtWQW1DU1o4eE9pSjZqZk0mZT0NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ ID4gZGhjd2dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiA+IG1hbl9saXN0aW5m b19kaGN3ZyZkPUR3SUdhUSZjPUxGWVotDQo+IG85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThz YzhTWThUDQo+ID4gcTR2cmZvZyZtPTMzYUFmRC1fRlIxS1JFMFY2eXBHRkRHUWRYLQ0KPiA5S1V6 aVRBMGFPVVBNX2ZjJnM9QXN0cVlkb29XRnluTGkNCj4gPiBxYTdOX1NjTWdoYmhoS1ZBbUNTWjh4 T2lKNmpmTSZlPQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4g M0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+ID4gbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9 TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4gOHNjOFNZOFQNCj4gPiBxNHZyZm9n Jm09MzNhQWZELV9GUjFLUkUwVjZ5cEdGREdRZFgtDQo+IDlLVXppVEEwYU9VUE1fZmMmcz1vQ01t SWZnaVFXVFpiQQ0KPiA+IDZSeDVMYWt4ZzZ0Yk8yZDJ2ZzVoOWFzUTZsblprJmU9DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaGN3ZyBt YWlsaW5nIGxpc3QNCj4gZGhjd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fZGhjd2cmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3po Qy04c2M4U1k4VHE0dnJmb2cmbT0zM2FBZkQtDQo+IF9GUjFLUkUwVjZ5cEdGREdRZFgtDQo+IDlL VXppVEEwYU9VUE1fZmMmcz1Bc3RxWWRvb1dGeW5MaXFhN05fU2NNZ2hiaGhLVkFtQ1NaOHhPaUo2 amYNCj4gTSZlPQ0K From nobody Tue Dec 10 09:24:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBA812080F for ; Tue, 10 Dec 2019 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPUwsMljnbJ2 for ; Tue, 10 Dec 2019 09:24:36 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24CC1208C7 for ; Tue, 10 Dec 2019 09:24:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 47XRkr1TqFz9vcGZ for ; Tue, 10 Dec 2019 17:24:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYGqUPR9Wo5a for ; Tue, 10 Dec 2019 11:24:35 -0600 (CST) Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 47XRkq5jJ5z9vcGT for ; Tue, 10 Dec 2019 11:24:35 -0600 (CST) Received: by mail-qk1-f200.google.com with SMTP id o184so12688921qkf.14 for ; Tue, 10 Dec 2019 09:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/XPt9kP48SiwsVkRVSVCbuxrBc6W/JHc01ZYyor8Jng=; b=WKysI175VDEYp8HgKH6E3JpiiPR01RSD0gQeFSRylarBVIAfIlAhE071X8F3AtH6KW gTQiEYMFEVzRU9j14PmiMQzGYEh+h5jsKoSGIK+8CNMAYMP8D2JYjgL+Dh1/K1vaLC6N Cg981GDH5KNNmRe9cLOLFHoF4egv9zA06tYvKWQlHSTjHIVO4NXj0ECIdSGch/6I9Lz5 MrBdszGsIBen6GjHwBTfMZl50jhH3ZNeRqsqHy75Qdt3uINHuateEWGPQxnUq+odUXZE 9xvhxbY7jkUCLt2NxyrvgLG2B48RJHHwVIZ674FtDVt6pVeFNs56ic5g31oVICAtH2wH Fs+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/XPt9kP48SiwsVkRVSVCbuxrBc6W/JHc01ZYyor8Jng=; b=VKHWb95YLRVywwRrvjVGmk1C9YwFOfjiNcGUgGYEwWwjO6bNGCbG9yQ8z6bj1UPiAt VQi007dpT3MVl1Owjvb072FrObxsDsjQD9vCXXS2xNdeijRXBsf9tXX0HfMNrfywUZTt /b5QKzXup3CsxX5K9wUmb2WoqZUh4MoYKElEZezPOMUOYZJuaY/j/ZDJGQbC/p9hMYZC gdOrpBUnnD0Cv1yZ62YF7crxSQYD78eWLtl4nsw42vt6TMFYZX/w4YMRz9f8jjSMBDmW dgggRfZcySjt2SUI/iXLFnzFqe6N2r2p4m/3p4gtIrhfUUmF/PzSH9xgqqZ1mL69bxlV QN/g== X-Gm-Message-State: APjAAAVxMtLMUIzK5FFAz7Xp8+rK7MN44qeIG8aoMcjUxfc6T14RxGw5 g3XF1l/m29tcLdFlT44gFVMUycm/qsLsZH1Rz9geXtcc76Zv1AvjmV7lxdYOaFtuSGMn/Exi8h4 X48gRvbgBYQLZIqthCzEVaVh4Fg== X-Received: by 2002:a0c:b5cd:: with SMTP id o13mr2707222qvf.47.1575998674447; Tue, 10 Dec 2019 09:24:34 -0800 (PST) X-Google-Smtp-Source: APXvYqwOMMZ4GMb7xALKl5ycT3m6/uhSUzYaF0XwlT9WA9l1dfzkNdHc/Jj5TTchdgMRq7Ddt/MBt+TR0UNCx0aGy7s= X-Received: by 2002:a0c:b5cd:: with SMTP id o13mr2707178qvf.47.1575998673815; Tue, 10 Dec 2019 09:24:33 -0800 (PST) MIME-Version: 1.0 References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: From: David Farmer Date: Tue, 10 Dec 2019 11:24:17 -0600 Message-ID: To: "Bernie Volz (volz)" Cc: Ted Lemon , "dhcwg@ietf.org" , V6 Ops List Content-Type: multipart/alternative; boundary="0000000000001e9e4705995cc9dc" Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 17:24:40 -0000 --0000000000001e9e4705995cc9dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bernie, Could you provide a couple of pointers to threads where the 0.0.0.0 address issue was discussed? I would like to better understand the issues around using 0.0.0.0 as the address returned, with making you re-debate the issue. Thanks On Tue, Dec 10, 2019 at 10:53 AM Bernie Volz (volz) wrote: > I've debated that issue on end and not going to do it any further. I > completely disagree - server should return whatever it would have returne= d > if the option is were not present. > > - Bernie > > -----Original Message----- > From: Ted Lemon > Sent: Tuesday, December 10, 2019 11:39 AM > To: Bernie Volz (volz) > Cc: mohamed.boucadair@orange.com; Jen Linkova ; > dhcwg@ietf.org; V6 Ops List > Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for > draft-link-dhc-v6only-01.txt > > I really think you should have a clear justification for doing anything > other than returning 0.0.0.0. Anything else is going to be more > complicated in the long term. The justification =E2=80=9Cbecause 0.0.0.= 0 would be > filtered out by the server=E2=80=9D seems like it=E2=80=99s very implemen= tation-dependent > and not really that big a deal. Is that your only reason? > > > On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) wrote: > > > > Hi: > > > > Is (8): > > > > (8) Consider returning an address from the range defined in > RFC7335 for IPv6-only hosts. Such IPv4 addresses are required anyway for > some IPv6-only hosts (those with a CLAT for example). > > > > =3D=3D=3D=3D > > The result is that 192.0.0.0/29 may be used in any system > > that requires IPv4 addresses for backward compatibility with > IPv4 > > communications in an IPv6-only network but does not emit IPv4 > packets > > "on the wire". > > =3D=3D=3D=3D > > > > But RFC7335 says (in section 4): > > > > IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], > > which is dedicated for DS-Lite. As defined in [RFC6333], this subnet > > is only present between the B4 and the Address Family Transition > > Router (AFTR) and never emits packets from this prefix "on the wire". > <--- > > 464XLAT has the same need for a non-routed IPv4 prefix, and this same > > need may be common for other similar solutions. It is most prudent > > and effective to generalize 192.0.0.0/29 for the use of supporting > > IPv4 interfaces in IPv6 transition technologies rather than reserving > > a prefix for every possible solution. > > > > So, this address is only used "on the host" (not on the wire), so why > would there be any need for the DHCP server to assign this address? > > > > And as the IPv6-only option means that the host never completes the > DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be > used to assign any address. > > > > - Bernie > > > > -----Original Message----- > > From: dhcwg On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, December 10, 2019 5:32 AM > > To: Jen Linkova ; dhcwg@ietf.org > > Cc: V6 Ops List > > Subject: Re: [dhcwg] Fwd: New Version Notification for > > draft-link-dhc-v6only-01.txt > > > > Hi Jen, > > > > Thank you for sharing this updated version. Below some points that I do > think need more clarification in the I-D: > > > > (1) The document is too NAT64 centric. The proposal may apply as well > for other IPv6-only deployment scenarios (typically, unmanaged IPv6-only > CPEs with IPv4aaS). > > > > (2) A discussion on the benefit of this extra signal compared to relyin= g > on existing signals (pref64, aftr_name, map_container...). For example, a > host that supports the option is ready to wait at minimum 300s and disabl= e > its IPv4 configuration regardless of what is happening on the IPv6 leg. H= ow > is that superior to a host delaying DHCP process by xxx ms should be > explained further. > > > > (3) How "IPv6-only preferred" mode is supposed to be set at the host > side: > > > > =3D=3D > > A DHCP client SHOULD allow a device administrator to configure > > IPv6-only preferred mode either for a specific interface (to indicate > > that the device is IPv6-only capable if connected to a NAT64 network > > via that interface) or for all interfaces. > > =3D=3D > > > > * I guess the default value when the option is supported by a host is t= o > disable including it in the request. The document should include a > discussion on the default behavior. > > * If an explicit action is needed from the user to enable including the > option, having a discussion to what extent the feature is likely to be > enabled would be needed. > > > > (4) The document is still mixing the DHCP client vs. host behaviors. > > For example, > > > > Clients not capable of operating in an IPv6-only NAT64 environment > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > MUST NOT include the IPv6-only Preferred option in the Parameter > > Request List of any DHCP packets and MUST ignore that option in > > packets received from DHCP servers. > > > > does not make sense for a DHCP client. > > > > Also, how the host is able to assess/determine that it is (not) capable > to behave in the IPv6 mode? > > > > (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., > RFC8585 says the following: > > > > "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition > > technologies for delivering IPv4 in IPv6-only connectivity. > > > > While yours is: > > > > IPv4-as-a-Service: a deployment scenario when end hosts are expected > > to operate in IPv6-only mode by default and IPv4 addresses can be > > assigned to some hosts if those hosts explicitly opt-in to receiving > > IPv4 addresses. > > > > (6) Do you consider a host with CLAT function as an IPv6-only host? > > > > If so, the following definition should be updated to refer to "IPv4 > connectivity" rather than "IPv4" in general. This is because an IPv4 > address is required for CLAT for example. > > > > =3D=3D > > IPv6-only capable host: a host which does not require IPv4 and can > > operate on IPv6-only networks. > > =3D=3D > > > > (7) Wouldn't the following add an extra delay for applications requirin= g > CLAT? > > > > =3D=3D > > The host MAY disable IPv4 stack > > completely for V6ONLY_WAIT seconds or until the network disconnection > > event happens. > > =3D=3D > > > > (8) Consider returning an address from the range defined in RFC7335 for > IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-on= ly > hosts (those with a CLAT for example). > > > > =3D=3D=3D=3D > > The result is that 192.0.0.0/29 may be used in any system > > that requires IPv4 addresses for backward compatibility with IPv4 > > communications in an IPv6-only network but does not emit IPv4 packets > > "on the wire". > > =3D=3D=3D=3D > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova > >> Envoy=C3=A9 : mardi 10 d=C3=A9cembre 2019 01:02 =C3=80 : dhcwg@ietf.or= g Cc : V6 Ops > >> List Objet : [dhcwg] Fwd: New Version Notification for > >> draft-link-dhc-v6only- 01.txt > >> > >> Hello, > >> > >> Thanks to everyone for very productive centi-thread on > >> draft-link-dhc-v6only-00 ;) > >> Here is the improved version, -01. > >> > >> The main changes: > >> > >> - The option is not zero length anymore. It has 4-bytes value which > >> might contain V6ONLY_WAIT timer. Benefits: > >> --- allows the network administrators to pilot the changes and > >> rollback quickly if needed; > >> --- addressed some concern about an option having zero length > >> (allegedly it might confuse some clients) > >> > >> - Using a dedicated address to return to clients is now an optional > >> optimisation. By default the server is expected just to return a > >> random address (as usual). > >> > >> - Typos fixed (probably some new typos added though). > >> > >> The authors would like the DHC WG to consider adopting this document. > >> > >> Thank you! > >> > >> ---------- Forwarded message --------- > >> From: > >> Date: Tue, Dec 10, 2019 at 10:44 AM > >> Subject: New Version Notification for draft-link-dhc-v6only-01.txt > >> To: Tomek Mrugalski , Lorenzo Colitti > >> , Jen Linkova , Michael C. > >> Richardson > >> > >> > >> > >> A new version of I-D, draft-link-dhc-v6only-01.txt has been > >> successfully submitted by Jen Linkova and posted to the IETF > >> repository. > >> > >> Name: draft-link-dhc-v6only > >> Revision: 01 > >> Title: IPv6-Only-Preferred Option for DHCP > >> Document date: 2019-12-09 > >> Group: Individual Submission > >> Pages: 10 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt > >> Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only= / > >> Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 > >> Htmlized: > https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only > >> Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6only-01 > >> > >> Abstract: > >> This document specifies a DHCP option to indicate that a host > >> supports an IPv6-only mode and willing to forgo obtaining an IPv4 > >> address if the network provides IPv6 connectivity. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> > >> -- > >> SY, Jen Linkova aka Furry > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > > 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000001e9e4705995cc9dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bernie,=C2=A0

Could you prov= ide a couple of pointers to threads where the 0.0.0.0 address issue was dis= cussed?

I would like to better understand the issu= es around using 0.0.0.0 as the address returned, with making you re-debate = the issue.

Thanks

On Tue, Dec 10, 2019 at 10:53 AM Bernie= Volz (volz) <volz@cisco.com> w= rote:
I've d= ebated that issue on end and not going to do it any further. I completely d= isagree - server should return whatever it would have returned if the optio= n is were not present.

- Bernie

-----Original Message-----
From: Ted Lemon <m= ellon@fugue.com>
Sent: Tuesday, December 10, 2019 11:39 AM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: moham= ed.boucadair@orange.com; Jen Linkova <furry13@gmail.com>; dhcwg@ietf.org; V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-d= hc-v6only-01.txt

I really think you should have a clear justification for doing anything oth= er than returning 0.0.0.0.=C2=A0 =C2=A0Anything else is going to be more co= mplicated in the long term.=C2=A0 =C2=A0The justification =E2=80=9Cbecause = 0.0.0.0 would be filtered out by the server=E2=80=9D seems like it=E2=80=99= s very implementation-dependent and not really that big a deal.=C2=A0 =C2= =A0Is that your only reason?

> On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
>
> Hi:
>
> Is (8):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(8) Consider returning an address from the r= ange defined in RFC7335 for IPv6-only hosts. Such IPv4 addresses are requir= ed anyway for some IPv6-only hosts (those with a CLAT for example).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The result is that 192.0.0.0/29 may be= used in any system
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that requires IPv4 addresses for bac= kward compatibility with IPv4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 communications in an IPv6-only netwo= rk but does not emit IPv4 packets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "on the wire".
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D
>
> But RFC7335 says (in section 4):
>
>=C2=A0 =C2=A0IANA has defined a well-known range, 192.0.0.0/29, in [RFC63= 33],
>=C2=A0 =C2=A0which is dedicated for DS-Lite.=C2=A0 As defined in [RFC63= 33], this subnet
>=C2=A0 =C2=A0is only present between the B4 and the Address Family Tran= sition
>=C2=A0 =C2=A0Router (AFTR) and never emits packets from this prefix &qu= ot;on the wire".=C2=A0 <---
>=C2=A0 =C2=A0464XLAT has the same need for a non-routed IPv4 prefix, an= d this same
>=C2=A0 =C2=A0need may be common for other similar solutions.=C2=A0 It i= s most prudent
>=C2=A0 =C2=A0and effective to generalize 192.0.0.0/29 for the use of supp= orting
>=C2=A0 =C2=A0IPv4 interfaces in IPv6 transition technologies rather tha= n reserving
>=C2=A0 =C2=A0a prefix for every possible solution.
>
> So, this address is only used "on the host" (not on the wire= ), so why would there be any need for the DHCP server to assign this addres= s?
>
> And as the IPv6-only option means that the host never completes the DH= CPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be used = to assign any address.
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of
> moha= med.boucadair@orange.com
> Sent: Tuesday, December 10, 2019 5:32 AM
> To: Jen Linkova <furry13@gmail.com>; dhcwg@ietf.org
> Cc: V6 Ops List <v6ops@ietf.org>
> Subject: Re: [dhcwg] Fwd: New Version Notification for
> draft-link-dhc-v6only-01.txt
>
> Hi Jen,
>
> Thank you for sharing this updated version. Below some points that I d= o think need more clarification in the I-D:
>
> (1) The document is too NAT64 centric. The proposal may apply as well = for other IPv6-only deployment scenarios (typically, unmanaged IPv6-only CP= Es with IPv4aaS).
>
> (2) A discussion on the benefit of this extra signal compared to relyi= ng on existing signals (pref64, aftr_name, map_container...). For example, = a host that supports the option is ready to wait at minimum 300s and disabl= e its IPv4 configuration regardless of what is happening on the IPv6 leg. H= ow is that superior to a host delaying DHCP process by xxx ms should be exp= lained further.=C2=A0
>
> (3) How "IPv6-only preferred" mode is supposed to be set at = the host side:
>
> =3D=3D
>=C2=A0 =C2=A0A DHCP client SHOULD allow a device administrator to confi= gure
>=C2=A0 =C2=A0IPv6-only preferred mode either for a specific interface (= to indicate
>=C2=A0 =C2=A0that the device is IPv6-only capable if connected to a NAT= 64 network
>=C2=A0 =C2=A0via that interface) or for all interfaces.=C2=A0
> =3D=3D
>
> * I guess the default value when the option is supported by a host is = to disable including it in the request. The document should include a discu= ssion on the default behavior.
> * If an explicit action is needed from the user to enable including th= e option, having a discussion to what extent the feature is likely to be en= abled would be needed.
>
> (4) The document is still mixing the DHCP client vs. host behaviors. <= br> > For example,
>
>=C2=A0 =C2=A0Clients not capable of operating in an IPv6-only NAT64 env= ironment
>=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0MUST NOT include the IPv6-only Preferred option in the Par= ameter
>=C2=A0 =C2=A0Request List of any DHCP packets and MUST ignore that opti= on in
>=C2=A0 =C2=A0packets received from DHCP servers.
>
> does not make sense for a DHCP client.
>
> Also, how the host is able to assess/determine that it is (not) capabl= e to behave in the IPv6 mode?
>
> (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RF= C8585 says the following:
>
>=C2=A0 =C2=A0"IPv4aaS" stands for "IPv4-as-a-Service&quo= t;, meaning transition
>=C2=A0 =C2=A0technologies for delivering IPv4 in IPv6-only connectivity= .
>
> While yours is:
>
>=C2=A0 =C2=A0IPv4-as-a-Service: a deployment scenario when end hosts ar= e expected
>=C2=A0 =C2=A0to operate in IPv6-only mode by default and IPv4 addresses= can be
>=C2=A0 =C2=A0assigned to some hosts if those hosts explicitly opt-in to= receiving
>=C2=A0 =C2=A0IPv4 addresses.
>
> (6) Do you consider a host with CLAT function as an IPv6-only host? >
> If so, the following definition should be updated to refer to "IP= v4 connectivity" rather than "IPv4" in general. This is beca= use an IPv4 address is required for CLAT for example.
>
> =3D=3D
>=C2=A0 =C2=A0IPv6-only capable host: a host which does not require IPv4= and can
>=C2=A0 =C2=A0operate on IPv6-only networks.
> =3D=3D
>
> (7) Wouldn't the following add an extra delay for applications req= uiring CLAT?
>
> =3D=3D
> The host MAY disable IPv4 stack
>=C2=A0 =C2=A0completely for V6ONLY_WAIT seconds or until the network di= sconnection
>=C2=A0 =C2=A0event happens.
> =3D=3D
>
> (8) Consider returning an address from the range defined in RFC7335 fo= r IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-on= ly hosts (those with a CLAT for example).
>
> =3D=3D=3D=3D
>=C2=A0 =C2=A0The result is that 192.0.0.0/29 may be used in any system >=C2=A0 =C2=A0that requires IPv4 addresses for backward compatibility wi= th IPv4
>=C2=A0 =C2=A0communications in an IPv6-only network but does not emit I= Pv4 packets
>=C2=A0 =C2=A0"on the wire".
> =3D=3D=3D=3D
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova
>> Envoy=C3=A9 : mardi 10 d=C3=A9cembre 2019 01:02 =C3=80 : dhcwg@ietf.org Cc : V6 Ops=
>> List Objet : [dhcwg] Fwd: New Version Notification for
>> draft-link-dhc-v6only- 01.txt
>>
>> Hello,
>>
>> Thanks to everyone for very productive centi-thread on
>> draft-link-dhc-v6only-00 ;)
>> Here is the improved version, -01.
>>
>> The main changes:
>>
>> - The option is not zero length anymore. It has 4-bytes value whic= h
>> might contain V6ONLY_WAIT timer. Benefits:
>>=C2=A0 =C2=A0 --- allows the network administrators to pilot the ch= anges and
>> rollback quickly if needed;
>>=C2=A0 =C2=A0 --- addressed some concern about an option having zer= o length
>> (allegedly it might confuse some clients)
>>
>> - Using a dedicated address to return to clients is now an optiona= l
>> optimisation. By default the server is expected just to return a <= br> >> random address (as usual).
>>
>> - Typos fixed (probably some new typos added though).
>>
>> The authors would like the DHC WG to consider adopting this docume= nt.
>>
>> Thank you!
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Tue, Dec 10, 2019 at 10:44 AM
>> Subject: New Version Notification for draft-link-dhc-v6only-01.txt=
>> To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Lorenzo Colitti <= br> >> <lorenz= o@google.com>, Jen Linkova <furry@google.com>, Michael C.
>> Richardson <mcr+ietf@sandelman.ca>
>>
>>
>>
>> A new version of I-D, draft-link-dhc-v6only-01.txt has been
>> successfully submitted by Jen Linkova and posted to the IETF
>> repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-link-dhc-v6onl= y
>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-Only-Preferred Optio= n for DHCP
>> Document date:=C2=A0 2019-12-09
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
>> URL:
>> https://www.ietf.org/inter= net-drafts/draft-link-dhc-v6only-01.txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-link-dhc-v6only-01
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only
>> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6only-01=
>>
>> Abstract:
>>=C2=A0 =C2=A0This document specifies a DHCP option to indicate that= a host
>>=C2=A0 =C2=A0supports an IPv6-only mode and willing to forgo obtain= ing an IPv4
>>=C2=A0 =C2=A0address if the network provides IPv6 connectivity.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of =
>> submission until the htmlized version and diff are available at >> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dhcwg<= br> >
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org=
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> 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


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=C2=A0 E= mail:farmer@umn.edu
Networking & Telecommunication Services
O= ffice of Information Technology
University of Minnesota=C2=A0=C2=A0
= 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Mi= nneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000001e9e4705995cc9dc-- From nobody Tue Dec 10 09:30:13 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6781208FA; Tue, 10 Dec 2019 09:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ1PbgaUQurc; Tue, 10 Dec 2019 09:30:00 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647DE12080F; Tue, 10 Dec 2019 09:30:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id xBAHTrCx006498; Tue, 10 Dec 2019 12:29:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1575998997; bh=c+FkJoJWP17n/lCEGzivjIHdRCNHg+a8h6/c9XsFb8Y=; h=From:To:CC:Subject:Date:From; b=bHWDaijqr7L3sKygep5+gCtpiucgOi4zg98laJ3psNM+ZHB3HCWOa/FaywzOdliTf Gb0ws86/A6SXpX4OBweLFXIXE1LNdsPDCkE7+B3+hvhYTrBhnzedWnmgQUzKJnHIkS GCo6rQgCelGXW0tMHcm7BskaNWs+RtYCNfbOfSs0ai83EuC1SEg1kaDzanIGiG0Fmi JpHfCYuYFSZyD9UTsNeMAtNIQGVF7htT2Ih5Z0AhQq1MAIGCJV80PTtUrCDq2yWYrI o0Z8qG6y7o69b9+IYlnBSPY8zX55AbpnhbLbvGC5pLHMmeNfD3Um3kkNOqpLaDTORC OIGjLOodVGUTQ== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id xBAHTj5Y004972 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 10 Dec 2019 12:29:45 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1779.2; Tue, 10 Dec 2019 09:29:44 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1779.002; Tue, 10 Dec 2019 09:29:44 -0800 From: "Templin (US), Fred L" To: "v6ops@ietf.org" CC: 6man WG , "atn@ietf.org" Thread-Topic: An IPv6 Air/Ground Interface for the International Civil Aviation Organization (Use Case) Thread-Index: AdWvfT/emTmbb+bVRQ6BEOg0Q9WLSw== Date: Tue, 10 Dec 2019 17:29:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 95DC827C17D96EB41254DE10B320B213D2B986DCCEBFCE8EFE1AF60DF020E9202000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: [v6ops] An IPv6 Air/Ground Interface for the International Civil Aviation Organization (Use Case) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 17:30:02 -0000 The International Civil Aviation Organization (ICAO) is building an Aeronau= tical Telecommunications Network with Internet Protocol Services (ATN/IPS). ICAO sees a use case for= an IPv6 Air/Ground (A/G) interface to support aircraft communications with ATN/IPS ground doma= in correspondents. This document discusses elements of the use case that have implications for= IPv6 operations. Please post any use case-oriented comments for this document on v6ops@ietf.= org. See also a document titled: "Transmission of IPv6 Packets over Aeronautical ("aero") I= nterfaces" posted on ipv6@ietf.org that presents a candidate solution. -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, December 10, 2019 8:58 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-icao-int-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : An IPv6 Air/Ground Interface for the Internationa= l Civil Aviation Organization (Use Case) Author : Fred L. Templin Filename : draft-templin-v6ops-icao-int-00.txt Pages : 5 Date : 2019-12-10 Abstract: The International Civil Aviation Organization (ICAO) is building a worldwide IPv6-based Air Traffic Management (ATM) service known as the Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). Aircraft connect to the ATN/IPS via an IPv6 Air/ Ground (A/G) interface that provides a nexus for control and data messages exchanges over all available aviation wireless data links. This document discusses the use case that motivates a new IPv6 interface abstraction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-icao-int/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-icao-int-00 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-icao-int-00 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/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 Tue Dec 10 10:08:17 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18459120964; Tue, 10 Dec 2019 10:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.256 X-Spam-Level: X-Spam-Status: No, score=-13.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 header.b=CiYpuiRs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0AJknqwc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejt_-RNsH2T2; Tue, 10 Dec 2019 10:08:08 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EE912096D; Tue, 10 Dec 2019 10:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47047; q=dns/txt; s=iport; t=1576001288; x=1577210888; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+XzORh0E/1JFsq3QEuynn3RHkkb7WTHWhqvRYq4sYw0=; b=CiYpuiRs1CgHimwEmTKaadix8CKglD6lWBK3ZFeRztpMVmRmjZUwIaj8 nojB+RxxxmgJ/gH293nS0BXENQ772N1zXpQJYgTwZR8rf6nabP+Qaw92x mhTDWDBSTZxp2n6bwXu4ls3Ss7TB0Efua3EB8sqp9WJgvDYjCTfeaqC2T M=; IronPort-PHdr: =?us-ascii?q?9a23=3AxPsZ3xMXSAtO2LhEFSUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQF0r/PtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AAD/3e9d/4UNJK1iAw4LAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQERAQEBAQEBAQEBAQGBfoEcLyknBWxYIAQLKoQDg0YDiwW?= =?us-ascii?q?CX4MEhleMLoF9gUKBEANQBAkBAQEMAQEYAQoKAgEBhEACFyiBRCQ4EwIDDQE?= =?us-ascii?q?BBAEBAQIBBQRthTcMhV4BAQEBAgEBARAICR0BAQkBIgkCAQQHAgICAQgRAgE?= =?us-ascii?q?BAQEBIAEGAwICAhkGBAILFAkIAgQOBRsHgjVLAYF5TQMOIAECDKNmAoE4iGF?= =?us-ascii?q?1gTKCfgEBBYECATIBAwIOQUCCUw0LghcJBYExhRyGfBqCAIERJyCCTD6CG0k?= =?us-ascii?q?BAQIBARiBFAESAQkSChEJAQwJCAmCSTKCLI06B4JnhVMkl1cvQwqCL4cjii2?= =?us-ascii?q?EIBuCQnSHApAAlw+BKAVqgnxIK4gAg2YCBAIEBQIOAQEFgT8qIjcwcXAVGiE?= =?us-ascii?q?qAYJBCUcRFIxmBwIaFYM7hRSFBDt0AQEBLneLUYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,300,1571702400"; d="scan'208,217";a="390163120" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 18:08:05 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAI84ID013444 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Dec 2019 18:08:05 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 12:08:04 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 13:08:02 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 12:08:01 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NP3pIvZ3U+hNl12pqOPVS6Xx53LSe0L6EPFpCyMTV6c3UCxqImYZv8wKJS8ZbqvO8JHTN8+ZcJ4W99G23wn434Jypb7Qpt2zOO11xl45hG/0Ntc4c9eHXG9FDj8VJaFl8HtV1hl4i2r2V9yMvjpdsQ5Dqo36n8W4zZNsJfRbgVD5hkVvR9/RWq+M/JXYfLPzABVhU6bGTGUfx4qWZ6sssuXwtPyQd63E00Oe/JoGclsssMves3+3LN58yu7ztxkFtM5WgwEHpIK2kBqAoM+l+H795tGQPiwPnDQDmg+fsv4cFver4muvrmngI96Gn0DjC1JuSao3Q/hbH3ynPAPvcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+XzORh0E/1JFsq3QEuynn3RHkkb7WTHWhqvRYq4sYw0=; b=KiOqW7GPBCC+0J75Jf/44II7P43jJVEO2y1Z7NjH90TIStZ7mhLD0GPrybe63fqPQrs5l7+rM13eFK6W85FyexxTJkTAv357Lrrw7d8MAJo7etddHkRmqoP+mwfQIK5MT+0E5F21t+Ix/Ht0YbXdqDVoae0Xgo9cl7rq7WW4K+WJQa2M8T3r4fgtXYAd9GrkbukH6QMjNKsvXXFZG2sWjIx0D/XjiO6L8ramWgT0F8l29PSSEBs9qwmynW+JjL1AvjWhgZSQaY6jH+t/5cWCbl9Wm4LPpatDZs8taweJu+M5+Ua38mp/GHRPbpsUlejGnCFTG3nWyB/Y6pcQhShftA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+XzORh0E/1JFsq3QEuynn3RHkkb7WTHWhqvRYq4sYw0=; b=0AJknqwc+2xFsdg/05uqOPYNBljCqidyg6UOlMem/CGizfS0z8CVjtsj3WujabEqyTvN+OKx+mWX9LnzYzCCLDQmWc8YZD+ssrKCPCPXWj2Bt8NtULXQzPtvpZyPukL1fwvsvdPIa4zrk/14p0+QXU4kKDEPe7cy5mA0KU+XFIs= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4091.namprd11.prod.outlook.com (20.176.126.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Tue, 10 Dec 2019 18:08:00 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 18:08:00 +0000 From: "Bernie Volz (volz)" To: David Farmer CC: Ted Lemon , "dhcwg@ietf.org" , "V6 Ops List" Thread-Topic: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKezkdaAgAADwfCAAAjMgP//uGSA Date: Tue, 10 Dec 2019 18:08:00 +0000 Message-ID: References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [2001:420:2c51:1321:98dc:6d83:1323:3c29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b687dcb0-0ed0-4712-732d-08d77d9be4b3 x-ms-traffictypediagnostic: DM6PR11MB4091: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6019001)(396003)(39860400002)(346002)(366004)(136003)(376002)(269900001)(13464003)(54164003)(189003)(199004)(6916009)(2906002)(86362001)(76116006)(54906003)(53546011)(15650500001)(6506007)(316002)(6486002)(2616005)(71200400001)(66574012)(6512007)(478600001)(186003)(64756008)(19627235002)(30864003)(5660300002)(81156014)(66946007)(91956017)(66446008)(33656002)(966005)(8936002)(81166006)(66476007)(4326008)(36756003)(66556008)(8676002)(21314003)(256605007)(16193025007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4091; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1hd/tP5+4L8NCxjkDNcWD5iRol0dhPRdWShNsV3vHlpFN4FtkPjzkuQwFlDcbmZGdJiS1idUup0sObDK9n02w6nffMlwcX8ThKbrr2JiBYCFMmOQ6u4+VY8GIbkGX4APUB32UKm9oKto13AJeQOhNVlKF1fhCKqej/eGzwpwFjheS+xPPrs8P5/BjNiLv5sKnOdAa5e6KzEgA26/XlPvhtMecbgTaj6TgEgGHpMI8gVLXTe+58RzQc4yRKtSJVdjKh8gyz1tYGUKpa/by3I4g27AgPTF1+S09t2yd/ROyjqZMZXsQHKWXOuaWHAVJRIe0dev1pbv9YTizDwiFgKfrlHy9Ps2K7K29nUQ/dA0feFrP9qSINcIHZ8MmW4nFMDYKuOmesMSyVOAEp4fQ9xpr3Mz4pt8SPvJRC5mDCOWoejtwylcCfB57hiByo9TpTd9As0/nRqCh8EekB2ilIMtymfL0YEmOnnANGyeZfDc7dFoZnie9+TiD9mOL56vuT3LeGtf2WC8xZv2mB1/ZLtq8otKeecmLcyq4O9mFxc765YUJc0noadn5Jo6i8MxV0eY9FhN6MrYqs1bBIvmXiiIXuNW2vWQoeTlKyClgJvTs+PzqM59Y0HHYXfYaXeE+c8v x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F6B54CA9BCF94E2CB431AC73954C99AEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b687dcb0-0ed0-4712-732d-08d77d9be4b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 18:08:00.5513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OGhVsoOaUHnTLx0SGvutt88hcKiDU0z2oi/D3D8aeQNl17Q7lvsTkk5HZpqjPQI7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4091 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 18:08:11 -0000 --_000_F6B54CA9BCF94E2CB431AC73954C99AEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiBwcm9iYWJseSBzZWUgbXVjaCBvZiB0aGUgZGlzY3Vzc2lvbiBieSBnb2luZyB0byBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL2RoY3dnLz9xPTAuMC4wLjAg KHNlYXJjaCBESEMgV0cgbWFpbGluZyBsaXN0IGZvciAwLjAuMC4wKSDigJMganVzdCBsb29rIGF0 IHRoZSByZWNlbnQgZW1haWxzIGZyb20gRGVjZW1iZXIgMjAxOS4NCg0KQlRXOiBJIGFtIHBlcnNv bmFsbHkgZG9uZSBkZWJhdGluZyB0aGUgaXNzdWUgKHRoaXMgaXMgbm90IGEgREhDIFdHIGNvLWNo YWlyIHN0YXRlbWVudCByZWxhdGVkIHRvIHRoZSBXRyBkaXNjdXNzaW9uKSwgYnV0IGp1c3QgdGhh dCBJIGFtIGRvbmUgZGViYXRpbmcgdGhpcyBteXNlbGYgKGFzIHRoZXJl4oCZcyBsaXR0bGUgcG9p bnQgaW4gcmVwZWF0aW5nIG15IGFyZ3VtZW50cykuIEl0IHdpbGwgYmUgdXAgdG8gdGhlIFdHIHRv IGRlY2lkZSAodmlhIHJvdWdoIGNvbnNlbnN1cykgYXMgdG8gd2hhdCBlbmRzIHVwIGluIHRoZSBk b2N1bWVudCBpZiBpdCBpcyBhZG9wdGVkLg0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9tOiBEYXZp ZCBGYXJtZXIgPGZhcm1lckB1bW4uZWR1Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTAsIDIw MTkgYXQgMTI6MjQgUE0NClRvOiBCZXJuaWUgVm9seiA8dm9sekBjaXNjby5jb20+DQpDYzogVGVk IExlbW9uIDxtZWxsb25AZnVndWUuY29tPiwgImRoY3dnQGlldGYub3JnIiA8ZGhjd2dAaWV0Zi5v cmc+LCAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZv cHNdIFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmst ZGhjLXY2b25seS0wMS50eHQNCg0KQmVybmllLA0KDQpDb3VsZCB5b3UgcHJvdmlkZSBhIGNvdXBs ZSBvZiBwb2ludGVycyB0byB0aHJlYWRzIHdoZXJlIHRoZSAwLjAuMC4wIGFkZHJlc3MgaXNzdWUg d2FzIGRpc2N1c3NlZD8NCg0KSSB3b3VsZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBp c3N1ZXMgYXJvdW5kIHVzaW5nIDAuMC4wLjAgYXMgdGhlIGFkZHJlc3MgcmV0dXJuZWQsIHdpdGgg bWFraW5nIHlvdSByZS1kZWJhdGUgdGhlIGlzc3VlLg0KDQpUaGFua3MNCg0KT24gVHVlLCBEZWMg MTAsIDIwMTkgYXQgMTA6NTMgQU0gQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbTxt YWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCkkndmUgZGViYXRlZCB0aGF0IGlzc3VlIG9u IGVuZCBhbmQgbm90IGdvaW5nIHRvIGRvIGl0IGFueSBmdXJ0aGVyLiBJIGNvbXBsZXRlbHkgZGlz YWdyZWUgLSBzZXJ2ZXIgc2hvdWxkIHJldHVybiB3aGF0ZXZlciBpdCB3b3VsZCBoYXZlIHJldHVy bmVkIGlmIHRoZSBvcHRpb24gaXMgd2VyZSBub3QgcHJlc2VudC4NCg0KLSBCZXJuaWUNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNv bTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+DQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxMCwg MjAxOSAxMTozOSBBTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFp bHRvOnZvbHpAY2lzY28uY29tPj4NCkNjOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNA Z21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT4+OyBkaGN3Z0BpZXRmLm9yZzxtYWls dG86ZGhjd2dAaWV0Zi5vcmc+OyBWNiBPcHMgTGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2 b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIFtkaGN3Z10gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50eHQNCg0KSSBy ZWFsbHkgdGhpbmsgeW91IHNob3VsZCBoYXZlIGEgY2xlYXIganVzdGlmaWNhdGlvbiBmb3IgZG9p bmcgYW55dGhpbmcgb3RoZXIgdGhhbiByZXR1cm5pbmcgMC4wLjAuMC4gICBBbnl0aGluZyBlbHNl IGlzIGdvaW5nIHRvIGJlIG1vcmUgY29tcGxpY2F0ZWQgaW4gdGhlIGxvbmcgdGVybS4gICBUaGUg anVzdGlmaWNhdGlvbiDigJxiZWNhdXNlIDAuMC4wLjAgd291bGQgYmUgZmlsdGVyZWQgb3V0IGJ5 IHRoZSBzZXJ2ZXLigJ0gc2VlbXMgbGlrZSBpdOKAmXMgdmVyeSBpbXBsZW1lbnRhdGlvbi1kZXBl bmRlbnQgYW5kIG5vdCByZWFsbHkgdGhhdCBiaWcgYSBkZWFsLiAgIElzIHRoYXQgeW91ciBvbmx5 IHJlYXNvbj8NCg0KPiBPbiBEZWMgMTAsIDIwMTksIGF0IDg6MTEgQU0sIEJlcm5pZSBWb2x6ICh2 b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+ IEhpOg0KPg0KPiBJcyAoOCk6DQo+DQo+ICAgICAgICg4KSBDb25zaWRlciByZXR1cm5pbmcgYW4g YWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGluIFJGQzczMzUgZm9yIElQdjYtb25seSBo b3N0cy4gU3VjaCBJUHY0IGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQgYW55d2F5IGZvciBzb21lIElQ djYtb25seSBob3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0KPg0KPiAgICAg ICA9PT09DQo+ICAgICAgICAgIFRoZSByZXN1bHQgaXMgdGhhdCAxOTIuMC4wLjAvMjk8aHR0cDov LzE5Mi4wLjAuMC8yOT4gbWF5IGJlIHVzZWQgaW4gYW55IHN5c3RlbQ0KPiAgICAgICAgICB0aGF0 IHJlcXVpcmVzIElQdjQgYWRkcmVzc2VzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgg SVB2NA0KPiAgICAgICAgICBjb21tdW5pY2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBi dXQgZG9lcyBub3QgZW1pdCBJUHY0IHBhY2tldHMNCj4gICAgICAgICAgIm9uIHRoZSB3aXJlIi4N Cj4gICAgICAgPT09PQ0KPg0KPiBCdXQgUkZDNzMzNSBzYXlzIChpbiBzZWN0aW9uIDQpOg0KPg0K PiAgIElBTkEgaGFzIGRlZmluZWQgYSB3ZWxsLWtub3duIHJhbmdlLCAxOTIuMC4wLjAvMjk8aHR0 cDovLzE5Mi4wLjAuMC8yOT4sIGluIFtSRkM2MzMzXSwNCj4gICB3aGljaCBpcyBkZWRpY2F0ZWQg Zm9yIERTLUxpdGUuICBBcyBkZWZpbmVkIGluIFtSRkM2MzMzXSwgdGhpcyBzdWJuZXQNCj4gICBp cyBvbmx5IHByZXNlbnQgYmV0d2VlbiB0aGUgQjQgYW5kIHRoZSBBZGRyZXNzIEZhbWlseSBUcmFu c2l0aW9uDQo+ICAgUm91dGVyIChBRlRSKSBhbmQgbmV2ZXIgZW1pdHMgcGFja2V0cyBmcm9tIHRo aXMgcHJlZml4ICJvbiB0aGUgd2lyZSIuICA8LS0tDQo+ICAgNDY0WExBVCBoYXMgdGhlIHNhbWUg bmVlZCBmb3IgYSBub24tcm91dGVkIElQdjQgcHJlZml4LCBhbmQgdGhpcyBzYW1lDQo+ICAgbmVl ZCBtYXkgYmUgY29tbW9uIGZvciBvdGhlciBzaW1pbGFyIHNvbHV0aW9ucy4gIEl0IGlzIG1vc3Qg cHJ1ZGVudA0KPiAgIGFuZCBlZmZlY3RpdmUgdG8gZ2VuZXJhbGl6ZSAxOTIuMC4wLjAvMjk8aHR0 cDovLzE5Mi4wLjAuMC8yOT4gZm9yIHRoZSB1c2Ugb2Ygc3VwcG9ydGluZw0KPiAgIElQdjQgaW50 ZXJmYWNlcyBpbiBJUHY2IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzIHJhdGhlciB0aGFuIHJlc2Vy dmluZw0KPiAgIGEgcHJlZml4IGZvciBldmVyeSBwb3NzaWJsZSBzb2x1dGlvbi4NCj4NCj4gU28s IHRoaXMgYWRkcmVzcyBpcyBvbmx5IHVzZWQgIm9uIHRoZSBob3N0IiAobm90IG9uIHRoZSB3aXJl KSwgc28gd2h5IHdvdWxkIHRoZXJlIGJlIGFueSBuZWVkIGZvciB0aGUgREhDUCBzZXJ2ZXIgdG8g YXNzaWduIHRoaXMgYWRkcmVzcz8NCj4NCj4gQW5kIGFzIHRoZSBJUHY2LW9ubHkgb3B0aW9uIG1l YW5zIHRoYXQgdGhlIGhvc3QgbmV2ZXIgY29tcGxldGVzIHRoZSBESENQRElTQ09WRVIvT0ZGRVIv UkVRVUVTVC9BQ0sgKHN0b3BzIGF0IE9GRkVSKSwgdGhpcyB3b3JrIGNvdWxkIG5vdCBiZSB1c2Vk IHRvIGFzc2lnbiBhbnkgYWRkcmVzcy4NCj4NCj4gLSBCZXJuaWUNCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGhjd2cgPGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YNCj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4g U2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTAsIDIwMTkgNTozMiBBTQ0KPiBUbzogSmVuIExpbmtv dmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT4+OyBkaGN3Z0Bp ZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+IENjOiBWNiBPcHMgTGlzdCA8djZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NCj4gU3ViamVjdDogUmU6IFtkaGN3Z10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LWxpbmstZGhjLXY2b25s eS0wMS50eHQNCj4NCj4gSGkgSmVuLA0KPg0KPiBUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhpcyB1 cGRhdGVkIHZlcnNpb24uIEJlbG93IHNvbWUgcG9pbnRzIHRoYXQgSSBkbyB0aGluayBuZWVkIG1v cmUgY2xhcmlmaWNhdGlvbiBpbiB0aGUgSS1EOg0KPg0KPiAoMSkgVGhlIGRvY3VtZW50IGlzIHRv byBOQVQ2NCBjZW50cmljLiBUaGUgcHJvcG9zYWwgbWF5IGFwcGx5IGFzIHdlbGwgZm9yIG90aGVy IElQdjYtb25seSBkZXBsb3ltZW50IHNjZW5hcmlvcyAodHlwaWNhbGx5LCB1bm1hbmFnZWQgSVB2 Ni1vbmx5IENQRXMgd2l0aCBJUHY0YWFTKS4NCj4NCj4gKDIpIEEgZGlzY3Vzc2lvbiBvbiB0aGUg YmVuZWZpdCBvZiB0aGlzIGV4dHJhIHNpZ25hbCBjb21wYXJlZCB0byByZWx5aW5nIG9uIGV4aXN0 aW5nIHNpZ25hbHMgKHByZWY2NCwgYWZ0cl9uYW1lLCBtYXBfY29udGFpbmVyLi4uKS4gRm9yIGV4 YW1wbGUsIGEgaG9zdCB0aGF0IHN1cHBvcnRzIHRoZSBvcHRpb24gaXMgcmVhZHkgdG8gd2FpdCBh dCBtaW5pbXVtIDMwMHMgYW5kIGRpc2FibGUgaXRzIElQdjQgY29uZmlndXJhdGlvbiByZWdhcmRs ZXNzIG9mIHdoYXQgaXMgaGFwcGVuaW5nIG9uIHRoZSBJUHY2IGxlZy4gSG93IGlzIHRoYXQgc3Vw ZXJpb3IgdG8gYSBob3N0IGRlbGF5aW5nIERIQ1AgcHJvY2VzcyBieSB4eHggbXMgc2hvdWxkIGJl IGV4cGxhaW5lZCBmdXJ0aGVyLg0KPg0KPiAoMykgSG93ICJJUHY2LW9ubHkgcHJlZmVycmVkIiBt b2RlIGlzIHN1cHBvc2VkIHRvIGJlIHNldCBhdCB0aGUgaG9zdCBzaWRlOg0KPg0KPiA9PQ0KPiAg IEEgREhDUCBjbGllbnQgU0hPVUxEIGFsbG93IGEgZGV2aWNlIGFkbWluaXN0cmF0b3IgdG8gY29u ZmlndXJlDQo+ICAgSVB2Ni1vbmx5IHByZWZlcnJlZCBtb2RlIGVpdGhlciBmb3IgYSBzcGVjaWZp YyBpbnRlcmZhY2UgKHRvIGluZGljYXRlDQo+ICAgdGhhdCB0aGUgZGV2aWNlIGlzIElQdjYtb25s eSBjYXBhYmxlIGlmIGNvbm5lY3RlZCB0byBhIE5BVDY0IG5ldHdvcmsNCj4gICB2aWEgdGhhdCBp bnRlcmZhY2UpIG9yIGZvciBhbGwgaW50ZXJmYWNlcy4NCj4gPT0NCj4NCj4gKiBJIGd1ZXNzIHRo ZSBkZWZhdWx0IHZhbHVlIHdoZW4gdGhlIG9wdGlvbiBpcyBzdXBwb3J0ZWQgYnkgYSBob3N0IGlz IHRvIGRpc2FibGUgaW5jbHVkaW5nIGl0IGluIHRoZSByZXF1ZXN0LiBUaGUgZG9jdW1lbnQgc2hv dWxkIGluY2x1ZGUgYSBkaXNjdXNzaW9uIG9uIHRoZSBkZWZhdWx0IGJlaGF2aW9yLg0KPiAqIElm IGFuIGV4cGxpY2l0IGFjdGlvbiBpcyBuZWVkZWQgZnJvbSB0aGUgdXNlciB0byBlbmFibGUgaW5j bHVkaW5nIHRoZSBvcHRpb24sIGhhdmluZyBhIGRpc2N1c3Npb24gdG8gd2hhdCBleHRlbnQgdGhl IGZlYXR1cmUgaXMgbGlrZWx5IHRvIGJlIGVuYWJsZWQgd291bGQgYmUgbmVlZGVkLg0KPg0KPiAo NCkgVGhlIGRvY3VtZW50IGlzIHN0aWxsIG1peGluZyB0aGUgREhDUCBjbGllbnQgdnMuIGhvc3Qg YmVoYXZpb3JzLg0KPiBGb3IgZXhhbXBsZSwNCj4NCj4gICBDbGllbnRzIG5vdCBjYXBhYmxlIG9m IG9wZXJhdGluZyBpbiBhbiBJUHY2LW9ubHkgTkFUNjQgZW52aXJvbm1lbnQNCj4gICBeXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4gICBNVVNUIE5PVCBp bmNsdWRlIHRoZSBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiBpbiB0aGUgUGFyYW1ldGVyDQo+ ICAgUmVxdWVzdCBMaXN0IG9mIGFueSBESENQIHBhY2tldHMgYW5kIE1VU1QgaWdub3JlIHRoYXQg b3B0aW9uIGluDQo+ICAgcGFja2V0cyByZWNlaXZlZCBmcm9tIERIQ1Agc2VydmVycy4NCj4NCj4g ZG9lcyBub3QgbWFrZSBzZW5zZSBmb3IgYSBESENQIGNsaWVudC4NCj4NCj4gQWxzbywgaG93IHRo ZSBob3N0IGlzIGFibGUgdG8gYXNzZXNzL2RldGVybWluZSB0aGF0IGl0IGlzIChub3QpIGNhcGFi bGUgdG8gYmVoYXZlIGluIHRoZSBJUHY2IG1vZGU/DQo+DQo+ICg1KSBUaGUgZGVmaW5pdGlvbiBv ZiBJUHY0YWFTIGlzIG5vdCBhbGlnbmVkIHdpdGggb3RoZXIgUkZDczogZS5nLiwgUkZDODU4NSBz YXlzIHRoZSBmb2xsb3dpbmc6DQo+DQo+ICAgIklQdjRhYVMiIHN0YW5kcyBmb3IgIklQdjQtYXMt YS1TZXJ2aWNlIiwgbWVhbmluZyB0cmFuc2l0aW9uDQo+ICAgdGVjaG5vbG9naWVzIGZvciBkZWxp dmVyaW5nIElQdjQgaW4gSVB2Ni1vbmx5IGNvbm5lY3Rpdml0eS4NCj4NCj4gV2hpbGUgeW91cnMg aXM6DQo+DQo+ICAgSVB2NC1hcy1hLVNlcnZpY2U6IGEgZGVwbG95bWVudCBzY2VuYXJpbyB3aGVu IGVuZCBob3N0cyBhcmUgZXhwZWN0ZWQNCj4gICB0byBvcGVyYXRlIGluIElQdjYtb25seSBtb2Rl IGJ5IGRlZmF1bHQgYW5kIElQdjQgYWRkcmVzc2VzIGNhbiBiZQ0KPiAgIGFzc2lnbmVkIHRvIHNv bWUgaG9zdHMgaWYgdGhvc2UgaG9zdHMgZXhwbGljaXRseSBvcHQtaW4gdG8gcmVjZWl2aW5nDQo+ ICAgSVB2NCBhZGRyZXNzZXMuDQo+DQo+ICg2KSBEbyB5b3UgY29uc2lkZXIgYSBob3N0IHdpdGgg Q0xBVCBmdW5jdGlvbiBhcyBhbiBJUHY2LW9ubHkgaG9zdD8NCj4NCj4gSWYgc28sIHRoZSBmb2xs b3dpbmcgZGVmaW5pdGlvbiBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZlciB0byAiSVB2NCBjb25u ZWN0aXZpdHkiIHJhdGhlciB0aGFuICJJUHY0IiBpbiBnZW5lcmFsLiBUaGlzIGlzIGJlY2F1c2Ug YW4gSVB2NCBhZGRyZXNzIGlzIHJlcXVpcmVkIGZvciBDTEFUIGZvciBleGFtcGxlLg0KPg0KPiA9 PQ0KPiAgIElQdjYtb25seSBjYXBhYmxlIGhvc3Q6IGEgaG9zdCB3aGljaCBkb2VzIG5vdCByZXF1 aXJlIElQdjQgYW5kIGNhbg0KPiAgIG9wZXJhdGUgb24gSVB2Ni1vbmx5IG5ldHdvcmtzLg0KPiA9 PQ0KPg0KPiAoNykgV291bGRuJ3QgdGhlIGZvbGxvd2luZyBhZGQgYW4gZXh0cmEgZGVsYXkgZm9y IGFwcGxpY2F0aW9ucyByZXF1aXJpbmcgQ0xBVD8NCj4NCj4gPT0NCj4gVGhlIGhvc3QgTUFZIGRp c2FibGUgSVB2NCBzdGFjaw0KPiAgIGNvbXBsZXRlbHkgZm9yIFY2T05MWV9XQUlUIHNlY29uZHMg b3IgdW50aWwgdGhlIG5ldHdvcmsgZGlzY29ubmVjdGlvbg0KPiAgIGV2ZW50IGhhcHBlbnMuDQo+ ID09DQo+DQo+ICg4KSBDb25zaWRlciByZXR1cm5pbmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5n ZSBkZWZpbmVkIGluIFJGQzczMzUgZm9yIElQdjYtb25seSBob3N0cy4gU3VjaCBJUHY0IGFkZHJl c3NlcyBhcmUgcmVxdWlyZWQgYW55d2F5IGZvciBzb21lIElQdjYtb25seSBob3N0cyAodGhvc2Ug d2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0KPg0KPiA9PT09DQo+ICAgVGhlIHJlc3VsdCBpcyB0 aGF0IDE5Mi4wLjAuMC8yOTxodHRwOi8vMTkyLjAuMC4wLzI5PiBtYXkgYmUgdXNlZCBpbiBhbnkg c3lzdGVtDQo+ICAgdGhhdCByZXF1aXJlcyBJUHY0IGFkZHJlc3NlcyBmb3IgYmFja3dhcmQgY29t cGF0aWJpbGl0eSB3aXRoIElQdjQNCj4gICBjb21tdW5pY2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkg bmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0IHBhY2tldHMNCj4gICAib24gdGhlIHdpcmUi Lg0KPiA9PT09DQo+DQo+IENoZWVycywNCj4gTWVkDQo+DQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4+IERlIDogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEgcGFydCBkZSBKZW4gTGlua292YQ0K Pj4gRW52b3nDqSA6IG1hcmRpIDEwIGTDqWNlbWJyZSAyMDE5IDAxOjAyIMOAIDogZGhjd2dAaWV0 Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPiBDYyA6IFY2IE9wcw0KPj4gTGlzdCBPYmpldCA6 IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiBkcmFmdC1saW5r LWRoYy12Nm9ubHktIDAxLnR4dA0KPj4NCj4+IEhlbGxvLA0KPj4NCj4+IFRoYW5rcyB0byBldmVy eW9uZSBmb3IgdmVyeSBwcm9kdWN0aXZlIGNlbnRpLXRocmVhZCBvbg0KPj4gZHJhZnQtbGluay1k aGMtdjZvbmx5LTAwIDspDQo+PiBIZXJlIGlzIHRoZSBpbXByb3ZlZCB2ZXJzaW9uLCAtMDEuDQo+ Pg0KPj4gVGhlIG1haW4gY2hhbmdlczoNCj4+DQo+PiAtIFRoZSBvcHRpb24gaXMgbm90IHplcm8g bGVuZ3RoIGFueW1vcmUuIEl0IGhhcyA0LWJ5dGVzIHZhbHVlIHdoaWNoDQo+PiBtaWdodCBjb250 YWluIFY2T05MWV9XQUlUIHRpbWVyLiBCZW5lZml0czoNCj4+ICAgIC0tLSBhbGxvd3MgdGhlIG5l dHdvcmsgYWRtaW5pc3RyYXRvcnMgdG8gcGlsb3QgdGhlIGNoYW5nZXMgYW5kDQo+PiByb2xsYmFj ayBxdWlja2x5IGlmIG5lZWRlZDsNCj4+ICAgIC0tLSBhZGRyZXNzZWQgc29tZSBjb25jZXJuIGFi b3V0IGFuIG9wdGlvbiBoYXZpbmcgemVybyBsZW5ndGgNCj4+IChhbGxlZ2VkbHkgaXQgbWlnaHQg Y29uZnVzZSBzb21lIGNsaWVudHMpDQo+Pg0KPj4gLSBVc2luZyBhIGRlZGljYXRlZCBhZGRyZXNz IHRvIHJldHVybiB0byBjbGllbnRzIGlzIG5vdyBhbiBvcHRpb25hbA0KPj4gb3B0aW1pc2F0aW9u LiBCeSBkZWZhdWx0IHRoZSBzZXJ2ZXIgaXMgZXhwZWN0ZWQganVzdCB0byByZXR1cm4gYQ0KPj4g cmFuZG9tIGFkZHJlc3MgKGFzIHVzdWFsKS4NCj4+DQo+PiAtIFR5cG9zIGZpeGVkIChwcm9iYWJs eSBzb21lIG5ldyB0eXBvcyBhZGRlZCB0aG91Z2gpLg0KPj4NCj4+IFRoZSBhdXRob3JzIHdvdWxk IGxpa2UgdGhlIERIQyBXRyB0byBjb25zaWRlciBhZG9wdGluZyB0aGlzIGRvY3VtZW50Lg0KPj4N Cj4+IFRoYW5rIHlvdSENCj4+DQo+PiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t LS0tLQ0KPj4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4NCj4+IERhdGU6IFR1ZSwgRGVjIDEwLCAyMDE5IGF0IDEwOjQ0IEFN DQo+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhj LXY2b25seS0wMS50eHQNCj4+IFRvOiBUb21layBNcnVnYWxza2kgPHRvbWFzei5tcnVnYWxza2lA Z21haWwuY29tPG1haWx0bzp0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbT4+LCBMb3JlbnpvIENv bGl0dGkNCj4+IDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+ LCBKZW4gTGlua292YSA8ZnVycnlAZ29vZ2xlLmNvbTxtYWlsdG86ZnVycnlAZ29vZ2xlLmNvbT4+ LCBNaWNoYWVsIEMuDQo+PiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E8bWFpbHRv Om1jciUyQmlldGZAc2FuZGVsbWFuLmNhPj4NCj4+DQo+Pg0KPj4NCj4+IEEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0IGhhcyBiZWVuDQo+PiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEplbiBMaW5rb3ZhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4+ IHJlcG9zaXRvcnkuDQo+Pg0KPj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhjLXY2b25s eQ0KPj4gUmV2aXNpb246ICAgICAgIDAxDQo+PiBUaXRsZTogICAgICAgICAgSVB2Ni1Pbmx5LVBy ZWZlcnJlZCBPcHRpb24gZm9yIERIQ1ANCj4+IERvY3VtZW50IGRhdGU6ICAyMDE5LTEyLTA5DQo+ PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+PiBQYWdlczogICAgICAg ICAgMTANCj4+IFVSTDoNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0DQo+PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluay1kaGMtdjZvbmx5Lw0KPj4gSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9u bHktMDENCj4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWxpbmstZGhjLXY2b25seQ0KPj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saW5rLWRoYy12Nm9ubHktMDENCj4+DQo+ PiBBYnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBESENQIG9wdGlvbiB0 byBpbmRpY2F0ZSB0aGF0IGEgaG9zdA0KPj4gICBzdXBwb3J0cyBhbiBJUHY2LW9ubHkgbW9kZSBh bmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4gSVB2NA0KPj4gICBhZGRyZXNzIGlmIHRo ZSBuZXR3b3JrIHByb3ZpZGVzIElQdjYgY29ubmVjdGl2aXR5Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+ IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQo+Pg0KPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+Pg0KPj4gLS0NCj4+IFNZ LCBKZW4gTGlua292YSBha2EgRnVycnkNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+PiBkaGN3Z0Bp ZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiBkaGN3Z0BpZXRmLm9y ZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGhjd2cNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0 bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KLS0N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBG YXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0Fm YXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0K T2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3Rh DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpNaW5u ZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENlbGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== --_000_F6B54CA9BCF94E2CB431AC73954C99AEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D782830F4FE62439449C4273EE81803@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzU0NjE2NTg7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yNjMxNjI4NiAtMTM1NjAyNDMzOCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNhbiBwcm9iYWJseSBzZWUgbXVjaCBvZiB0aGUg ZGlzY3Vzc2lvbiBieSBnb2luZyB0byA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL2RoY3dnLz9xPTAuMC4wLjAiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL2Jyb3dzZS9kaGN3Zy8/cT0wLjAuMC4wPC9hPiAoc2VhcmNoIERIQyBXRyBt YWlsaW5nIGxpc3QgZm9yIDAuMC4wLjApIOKAkyBqdXN0IGxvb2sgYXQgdGhlIHJlY2VudCBlbWFp bHMgZnJvbSBEZWNlbWJlciAyMDE5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFc6IEkgYW0g cGVyc29uYWxseSBkb25lIGRlYmF0aW5nIHRoZSBpc3N1ZSAodGhpcyBpcyBub3QgYSBESEMgV0cg Y28tY2hhaXIgc3RhdGVtZW50IHJlbGF0ZWQgdG8gdGhlIFdHIGRpc2N1c3Npb24pLCBidXQganVz dCB0aGF0IEkgYW0gZG9uZSBkZWJhdGluZyB0aGlzIG15c2VsZiAoYXMgdGhlcmXigJlzIGxpdHRs ZSBwb2ludCBpbiByZXBlYXRpbmcgbXkgYXJndW1lbnRzKS4gSXQgd2lsbCBiZSB1cCB0byB0aGUN CiBXRyB0byBkZWNpZGUgKHZpYSByb3VnaCBjb25zZW5zdXMpIGFzIHRvIHdoYXQgZW5kcyB1cCBp biB0aGUgZG9jdW1lbnQgaWYgaXQgaXMgYWRvcHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkJlcm5pZTxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RGF2aWQgRmFybWVyICZsdDtm YXJtZXJAdW1uLmVkdSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRGVjZW1iZXIgMTAs IDIwMTkgYXQgMTI6MjQgUE08YnI+DQo8Yj5UbzogPC9iPkJlcm5pZSBWb2x6ICZsdDt2b2x6QGNp c2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNv bSZndDssICZxdW90O2RoY3dnQGlldGYub3JnJnF1b3Q7ICZsdDtkaGN3Z0BpZXRmLm9yZyZndDss ICZxdW90O3Y2b3BzQGlldGYub3JnJnF1b3Q7ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFt2Nm9wc10gW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlcm5p ZSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q291bGQgeW91IHByb3ZpZGUgYSBjb3VwbGUgb2YgcG9pbnRlcnMgdG8gdGhyZWFkcyB3 aGVyZSB0aGUgMC4wLjAuMCBhZGRyZXNzIGlzc3VlIHdhcyBkaXNjdXNzZWQ/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0 byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgaXNzdWVzIGFyb3VuZCB1c2luZyAwLjAuMC4wIGFzIHRo ZSBhZGRyZXNzIHJldHVybmVkLCB3aXRoIG1ha2luZyB5b3UgcmUtZGViYXRlIHRoZSBpc3N1ZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEw LCAyMDE5IGF0IDEwOjUzIEFNIEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnZvbHpAY2lzY28uY29tIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBkZWJh dGVkIHRoYXQgaXNzdWUgb24gZW5kIGFuZCBub3QgZ29pbmcgdG8gZG8gaXQgYW55IGZ1cnRoZXIu IEkgY29tcGxldGVseSBkaXNhZ3JlZSAtIHNlcnZlciBzaG91bGQgcmV0dXJuIHdoYXRldmVyIGl0 IHdvdWxkIGhhdmUgcmV0dXJuZWQgaWYgdGhlIG9wdGlvbiBpcyB3ZXJlIG5vdCBwcmVzZW50Ljxi cj4NCjxicj4NCi0gQmVybmllPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBUZWQgTGVtb24gJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWVsbG9uQGZ1Z3VlLmNvbTwvYT4mZ3Q7DQo8YnI+DQpTZW50OiBU dWVzZGF5LCBEZWNlbWJlciAxMCwgMjAxOSAxMTozOSBBTTxicj4NClRvOiBCZXJuaWUgVm9seiAo dm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2x6QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZvbHpAY2lzY28uY29tPC9hPiZndDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPjsgSmVuIExpbmtvdmEgJmx0OzxhIGhyZWY9Im1haWx0bzpmdXJyeTEzQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZ1cnJ5MTNAZ21haWwuY29tPC9hPiZndDs7DQo8YSBo cmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kaGN3Z0BpZXRmLm9y ZzwvYT47IFY2IE9wcyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFt2 Nm9wc10gW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGlu ay1kaGMtdjZvbmx5LTAxLnR4dDxicj4NCjxicj4NCkkgcmVhbGx5IHRoaW5rIHlvdSBzaG91bGQg aGF2ZSBhIGNsZWFyIGp1c3RpZmljYXRpb24gZm9yIGRvaW5nIGFueXRoaW5nIG90aGVyIHRoYW4g cmV0dXJuaW5nIDAuMC4wLjAuJm5ic3A7ICZuYnNwO0FueXRoaW5nIGVsc2UgaXMgZ29pbmcgdG8g YmUgbW9yZSBjb21wbGljYXRlZCBpbiB0aGUgbG9uZyB0ZXJtLiZuYnNwOyAmbmJzcDtUaGUganVz dGlmaWNhdGlvbiDigJxiZWNhdXNlIDAuMC4wLjAgd291bGQgYmUgZmlsdGVyZWQgb3V0IGJ5IHRo ZSBzZXJ2ZXLigJ0gc2VlbXMgbGlrZSBpdOKAmXMNCiB2ZXJ5IGltcGxlbWVudGF0aW9uLWRlcGVu ZGVudCBhbmQgbm90IHJlYWxseSB0aGF0IGJpZyBhIGRlYWwuJm5ic3A7ICZuYnNwO0lzIHRoYXQg eW91ciBvbmx5IHJlYXNvbj88YnI+DQo8YnI+DQomZ3Q7IE9uIERlYyAxMCwgMjAxOSwgYXQgODox MSBBTSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgPGJyPg0KJmd0OyBIaTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSXMgKDgpOjxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyg4KSBDb25zaWRlciByZXR1cm5p bmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGluIFJGQzczMzUgZm9yIElQdjYt b25seSBob3N0cy4gU3VjaCBJUHY0IGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQgYW55d2F5IGZvciBz b21lIElQdjYtb25seSBob3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLjxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz09PT08YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgcmVzdWx0IGlzIHRoYXQgPGEg aHJlZj0iaHR0cDovLzE5Mi4wLjAuMC8yOSIgdGFyZ2V0PSJfYmxhbmsiPjE5Mi4wLjAuMC8yOTwv YT4gbWF5IGJlIHVzZWQgaW4gYW55IHN5c3RlbTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHRoYXQgcmVxdWlyZXMgSVB2NCBhZGRyZXNzZXMgZm9yIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgY29tbXVuaWNhdGlvbnMgaW4gYW4gSVB2Ni1vbmx5IG5ldHdvcmsgYnV0IGRv ZXMgbm90IGVtaXQgSVB2NCBwYWNrZXRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7b24gdGhlIHdpcmUmcXVvdDsuPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOz09PT08YnI+DQomZ3Q7IDxicj4NCiZndDsgQnV0IFJGQzczMzUgc2F5 cyAoaW4gc2VjdGlvbiA0KTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7SUFOQSBo YXMgZGVmaW5lZCBhIHdlbGwta25vd24gcmFuZ2UsIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMC4wLjAv MjkiIHRhcmdldD0iX2JsYW5rIj4NCjE5Mi4wLjAuMC8yOTwvYT4sIGluIFtSRkM2MzMzXSw8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO3doaWNoIGlzIGRlZGljYXRlZCBmb3IgRFMtTGl0ZS4mbmJzcDsg QXMgZGVmaW5lZCBpbiBbUkZDNjMzM10sIHRoaXMgc3VibmV0PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDtpcyBvbmx5IHByZXNlbnQgYmV0d2VlbiB0aGUgQjQgYW5kIHRoZSBBZGRyZXNzIEZhbWlseSBU cmFuc2l0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtSb3V0ZXIgKEFGVFIpIGFuZCBuZXZlciBl bWl0cyBwYWNrZXRzIGZyb20gdGhpcyBwcmVmaXggJnF1b3Q7b24gdGhlIHdpcmUmcXVvdDsuJm5i c3A7ICZsdDstLS08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOzQ2NFhMQVQgaGFzIHRoZSBzYW1lIG5l ZWQgZm9yIGEgbm9uLXJvdXRlZCBJUHY0IHByZWZpeCwgYW5kIHRoaXMgc2FtZTxicj4NCiZndDsm bmJzcDsgJm5ic3A7bmVlZCBtYXkgYmUgY29tbW9uIGZvciBvdGhlciBzaW1pbGFyIHNvbHV0aW9u cy4mbmJzcDsgSXQgaXMgbW9zdCBwcnVkZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthbmQgZWZm ZWN0aXZlIHRvIGdlbmVyYWxpemUgPGEgaHJlZj0iaHR0cDovLzE5Mi4wLjAuMC8yOSIgdGFyZ2V0 PSJfYmxhbmsiPjE5Mi4wLjAuMC8yOTwvYT4gZm9yIHRoZSB1c2Ugb2Ygc3VwcG9ydGluZzxicj4N CiZndDsmbmJzcDsgJm5ic3A7SVB2NCBpbnRlcmZhY2VzIGluIElQdjYgdHJhbnNpdGlvbiB0ZWNo bm9sb2dpZXMgcmF0aGVyIHRoYW4gcmVzZXJ2aW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthIHBy ZWZpeCBmb3IgZXZlcnkgcG9zc2libGUgc29sdXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNv LCB0aGlzIGFkZHJlc3MgaXMgb25seSB1c2VkICZxdW90O29uIHRoZSBob3N0JnF1b3Q7IChub3Qg b24gdGhlIHdpcmUpLCBzbyB3aHkgd291bGQgdGhlcmUgYmUgYW55IG5lZWQgZm9yIHRoZSBESENQ IHNlcnZlciB0byBhc3NpZ24gdGhpcyBhZGRyZXNzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBBbmQg YXMgdGhlIElQdjYtb25seSBvcHRpb24gbWVhbnMgdGhhdCB0aGUgaG9zdCBuZXZlciBjb21wbGV0 ZXMgdGhlIERIQ1BESVNDT1ZFUi9PRkZFUi9SRVFVRVNUL0FDSyAoc3RvcHMgYXQgT0ZGRVIpLCB0 aGlzIHdvcmsgY291bGQgbm90IGJlIHVzZWQgdG8gYXNzaWduIGFueSBhZGRyZXNzLjxicj4NCiZn dDsgPGJyPg0KJmd0OyAtIEJlcm5pZTxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpk aGN3Zy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZg0KPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+PGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxMCwg MjAxOSA1OjMyIEFNPGJyPg0KJmd0OyBUbzogSmVuIExpbmtvdmEgJmx0OzxhIGhyZWY9Im1haWx0 bzpmdXJyeTEzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZ1cnJ5MTNAZ21haWwuY29tPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5k aGN3Z0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiBWNiBPcHMgTGlzdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIDxicj4NCiZndDsgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dDxicj4N CiZndDsgPGJyPg0KJmd0OyBIaSBKZW4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBm b3Igc2hhcmluZyB0aGlzIHVwZGF0ZWQgdmVyc2lvbi4gQmVsb3cgc29tZSBwb2ludHMgdGhhdCBJ IGRvIHRoaW5rIG5lZWQgbW9yZSBjbGFyaWZpY2F0aW9uIGluIHRoZSBJLUQ6DQo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgKDEpIFRoZSBkb2N1bWVudCBpcyB0b28gTkFUNjQgY2VudHJpYy4gVGhlIHBy b3Bvc2FsIG1heSBhcHBseSBhcyB3ZWxsIGZvciBvdGhlciBJUHY2LW9ubHkgZGVwbG95bWVudCBz Y2VuYXJpb3MgKHR5cGljYWxseSwgdW5tYW5hZ2VkIElQdjYtb25seSBDUEVzIHdpdGggSVB2NGFh UykuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICgyKSBBIGRpc2N1c3Npb24gb24gdGhlIGJlbmVmaXQg b2YgdGhpcyBleHRyYSBzaWduYWwgY29tcGFyZWQgdG8gcmVseWluZyBvbiBleGlzdGluZyBzaWdu YWxzIChwcmVmNjQsIGFmdHJfbmFtZSwgbWFwX2NvbnRhaW5lci4uLikuIEZvciBleGFtcGxlLCBh IGhvc3QgdGhhdCBzdXBwb3J0cyB0aGUgb3B0aW9uIGlzIHJlYWR5IHRvIHdhaXQgYXQgbWluaW11 bSAzMDBzIGFuZCBkaXNhYmxlIGl0cyBJUHY0IGNvbmZpZ3VyYXRpb24gcmVnYXJkbGVzcw0KIG9m IHdoYXQgaXMgaGFwcGVuaW5nIG9uIHRoZSBJUHY2IGxlZy4gSG93IGlzIHRoYXQgc3VwZXJpb3Ig dG8gYSBob3N0IGRlbGF5aW5nIERIQ1AgcHJvY2VzcyBieSB4eHggbXMgc2hvdWxkIGJlIGV4cGxh aW5lZCBmdXJ0aGVyLiZuYnNwOw0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICgzKSBIb3cgJnF1b3Q7 SVB2Ni1vbmx5IHByZWZlcnJlZCZxdW90OyBtb2RlIGlzIHN1cHBvc2VkIHRvIGJlIHNldCBhdCB0 aGUgaG9zdCBzaWRlOjxicj4NCiZndDsgPGJyPg0KJmd0OyA9PTxicj4NCiZndDsmbmJzcDsgJm5i c3A7QSBESENQIGNsaWVudCBTSE9VTEQgYWxsb3cgYSBkZXZpY2UgYWRtaW5pc3RyYXRvciB0byBj b25maWd1cmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0lQdjYtb25seSBwcmVmZXJyZWQgbW9kZSBl aXRoZXIgZm9yIGEgc3BlY2lmaWMgaW50ZXJmYWNlICh0byBpbmRpY2F0ZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7dGhhdCB0aGUgZGV2aWNlIGlzIElQdjYtb25seSBjYXBhYmxlIGlmIGNvbm5lY3Rl ZCB0byBhIE5BVDY0IG5ldHdvcms8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3ZpYSB0aGF0IGludGVy ZmFjZSkgb3IgZm9yIGFsbCBpbnRlcmZhY2VzLiZuYnNwOyA8YnI+DQomZ3Q7ID09PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ICogSSBndWVzcyB0aGUgZGVmYXVsdCB2YWx1ZSB3aGVuIHRoZSBvcHRpb24g aXMgc3VwcG9ydGVkIGJ5IGEgaG9zdCBpcyB0byBkaXNhYmxlIGluY2x1ZGluZyBpdCBpbiB0aGUg cmVxdWVzdC4gVGhlIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvbiB0aGUg ZGVmYXVsdCBiZWhhdmlvci4NCjxicj4NCiZndDsgKiBJZiBhbiBleHBsaWNpdCBhY3Rpb24gaXMg bmVlZGVkIGZyb20gdGhlIHVzZXIgdG8gZW5hYmxlIGluY2x1ZGluZyB0aGUgb3B0aW9uLCBoYXZp bmcgYSBkaXNjdXNzaW9uIHRvIHdoYXQgZXh0ZW50IHRoZSBmZWF0dXJlIGlzIGxpa2VseSB0byBi ZSBlbmFibGVkIHdvdWxkIGJlIG5lZWRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgKDQpIFRoZSBk b2N1bWVudCBpcyBzdGlsbCBtaXhpbmcgdGhlIERIQ1AgY2xpZW50IHZzLiBob3N0IGJlaGF2aW9y cy4gPGJyPg0KJmd0OyBGb3IgZXhhbXBsZSw8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5i c3A7Q2xpZW50cyBub3QgY2FwYWJsZSBvZiBvcGVyYXRpbmcgaW4gYW4gSVB2Ni1vbmx5IE5BVDY0 IGVudmlyb25tZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDteXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO01VU1QgTk9U IGluY2x1ZGUgdGhlIElQdjYtb25seSBQcmVmZXJyZWQgb3B0aW9uIGluIHRoZSBQYXJhbWV0ZXI8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1JlcXVlc3QgTGlzdCBvZiBhbnkgREhDUCBwYWNrZXRzIGFu ZCBNVVNUIGlnbm9yZSB0aGF0IG9wdGlvbiBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7cGFja2V0 cyByZWNlaXZlZCBmcm9tIERIQ1Agc2VydmVycy48YnI+DQomZ3Q7IDxicj4NCiZndDsgZG9lcyBu b3QgbWFrZSBzZW5zZSBmb3IgYSBESENQIGNsaWVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFs c28sIGhvdyB0aGUgaG9zdCBpcyBhYmxlIHRvIGFzc2Vzcy9kZXRlcm1pbmUgdGhhdCBpdCBpcyAo bm90KSBjYXBhYmxlIHRvIGJlaGF2ZSBpbiB0aGUgSVB2NiBtb2RlPw0KPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICg1KSBUaGUgZGVmaW5pdGlvbiBvZiBJUHY0YWFTIGlzIG5vdCBhbGlnbmVkIHdpdGgg b3RoZXIgUkZDczogZS5nLiwgUkZDODU4NSBzYXlzIHRoZSBmb2xsb3dpbmc6DQo8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7JnF1b3Q7SVB2NGFhUyZxdW90OyBzdGFuZHMgZm9yICZx dW90O0lQdjQtYXMtYS1TZXJ2aWNlJnF1b3Q7LCBtZWFuaW5nIHRyYW5zaXRpb248YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwO3RlY2hub2xvZ2llcyBmb3IgZGVsaXZlcmluZyBJUHY0IGluIElQdjYtb25s eSBjb25uZWN0aXZpdHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoaWxlIHlvdXJzIGlzOiA8YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7SVB2NC1hcy1hLVNlcnZpY2U6IGEgZGVwbG95 bWVudCBzY2VuYXJpbyB3aGVuIGVuZCBob3N0cyBhcmUgZXhwZWN0ZWQ8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO3RvIG9wZXJhdGUgaW4gSVB2Ni1vbmx5IG1vZGUgYnkgZGVmYXVsdCBhbmQgSVB2NCBh ZGRyZXNzZXMgY2FuIGJlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthc3NpZ25lZCB0byBzb21lIGhv c3RzIGlmIHRob3NlIGhvc3RzIGV4cGxpY2l0bHkgb3B0LWluIHRvIHJlY2VpdmluZzxicj4NCiZn dDsmbmJzcDsgJm5ic3A7SVB2NCBhZGRyZXNzZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICg2KSBE byB5b3UgY29uc2lkZXIgYSBob3N0IHdpdGggQ0xBVCBmdW5jdGlvbiBhcyBhbiBJUHY2LW9ubHkg aG9zdD88YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgc28sIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlv biBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZlciB0byAmcXVvdDtJUHY0IGNvbm5lY3Rpdml0eSZx dW90OyByYXRoZXIgdGhhbiAmcXVvdDtJUHY0JnF1b3Q7IGluIGdlbmVyYWwuIFRoaXMgaXMgYmVj YXVzZSBhbiBJUHY0IGFkZHJlc3MgaXMgcmVxdWlyZWQgZm9yIENMQVQgZm9yIGV4YW1wbGUuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ID09PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtJUHY2LW9ubHkgY2Fw YWJsZSBob3N0OiBhIGhvc3Qgd2hpY2ggZG9lcyBub3QgcmVxdWlyZSBJUHY0IGFuZCBjYW48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwO29wZXJhdGUgb24gSVB2Ni1vbmx5IG5ldHdvcmtzLjxicj4NCiZn dDsgPT08YnI+DQomZ3Q7IDxicj4NCiZndDsgKDcpIFdvdWxkbid0IHRoZSBmb2xsb3dpbmcgYWRk IGFuIGV4dHJhIGRlbGF5IGZvciBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nIENMQVQ/PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ID09PGJyPg0KJmd0OyBUaGUgaG9zdCBNQVkgZGlzYWJsZSBJUHY0IHN0YWNr PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjb21wbGV0ZWx5IGZvciBWNk9OTFlfV0FJVCBzZWNvbmRz IG9yIHVudGlsIHRoZSBuZXR3b3JrIGRpc2Nvbm5lY3Rpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw O2V2ZW50IGhhcHBlbnMuPGJyPg0KJmd0OyA9PTxicj4NCiZndDsgPGJyPg0KJmd0OyAoOCkgQ29u c2lkZXIgcmV0dXJuaW5nIGFuIGFkZHJlc3MgZnJvbSB0aGUgcmFuZ2UgZGVmaW5lZCBpbiBSRkM3 MzM1IGZvciBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMgYXJlIHJlcXVpcmVk IGFueXdheSBmb3Igc29tZSBJUHY2LW9ubHkgaG9zdHMgKHRob3NlIHdpdGggYSBDTEFUIGZvciBl eGFtcGxlKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 VGhlIHJlc3VsdCBpcyB0aGF0IDxhIGhyZWY9Imh0dHA6Ly8xOTIuMC4wLjAvMjkiIHRhcmdldD0i X2JsYW5rIj4xOTIuMC4wLjAvMjk8L2E+IG1heSBiZSB1c2VkIGluIGFueSBzeXN0ZW08YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO3RoYXQgcmVxdWlyZXMgSVB2NCBhZGRyZXNzZXMgZm9yIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjb21tdW5pY2F0 aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0IHBhY2tl dHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyZxdW90O29uIHRoZSB3aXJlJnF1b3Q7Ljxicj4NCiZn dDsgPT09PTxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBNZWQ8YnI+DQom Z3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsm Z3Q7IERlIDogZGhjd2cgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBw YXJ0IGRlIEplbiBMaW5rb3ZhDQo8YnI+DQomZ3Q7Jmd0OyBFbnZvecOpIDogbWFyZGkgMTAgZMOp Y2VtYnJlIDIwMTkgMDE6MDIgw4AgOiA8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCmRoY3dnQGlldGYub3JnPC9hPiBDYyA6IFY2IE9wcyA8YnI+DQomZ3Q7 Jmd0OyBMaXN0IE9iamV0IDogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3I8YnI+DQomZ3Q7Jmd0OyBkcmFmdC1saW5rLWRoYy12Nm9ubHktIDAxLnR4dDxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7IEhlbGxvLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRo YW5rcyB0byBldmVyeW9uZSBmb3IgdmVyeSBwcm9kdWN0aXZlIGNlbnRpLXRocmVhZCBvbjxicj4N CiZndDsmZ3Q7IGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMCA7KTxicj4NCiZndDsmZ3Q7IEhlcmUg aXMgdGhlIGltcHJvdmVkIHZlcnNpb24sIC0wMS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyBUaGUgbWFpbiBjaGFuZ2VzOjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0gVGhlIG9w dGlvbiBpcyBub3QgemVybyBsZW5ndGggYW55bW9yZS4gSXQgaGFzIDQtYnl0ZXMgdmFsdWUgd2hp Y2ggPGJyPg0KJmd0OyZndDsgbWlnaHQgY29udGFpbiBWNk9OTFlfV0FJVCB0aW1lci4gQmVuZWZp dHM6PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IC0tLSBhbGxvd3MgdGhlIG5ldHdvcmsgYWRt aW5pc3RyYXRvcnMgdG8gcGlsb3QgdGhlIGNoYW5nZXMgYW5kIDxicj4NCiZndDsmZ3Q7IHJvbGxi YWNrIHF1aWNrbHkgaWYgbmVlZGVkOzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAtLS0gYWRk cmVzc2VkIHNvbWUgY29uY2VybiBhYm91dCBhbiBvcHRpb24gaGF2aW5nIHplcm8gbGVuZ3RoIDxi cj4NCiZndDsmZ3Q7IChhbGxlZ2VkbHkgaXQgbWlnaHQgY29uZnVzZSBzb21lIGNsaWVudHMpPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLSBVc2luZyBhIGRlZGljYXRlZCBhZGRyZXNzIHRv IHJldHVybiB0byBjbGllbnRzIGlzIG5vdyBhbiBvcHRpb25hbCA8YnI+DQomZ3Q7Jmd0OyBvcHRp bWlzYXRpb24uIEJ5IGRlZmF1bHQgdGhlIHNlcnZlciBpcyBleHBlY3RlZCBqdXN0IHRvIHJldHVy biBhIDxicj4NCiZndDsmZ3Q7IHJhbmRvbSBhZGRyZXNzIChhcyB1c3VhbCkuPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgLSBUeXBvcyBmaXhlZCAocHJvYmFibHkgc29tZSBuZXcgdHlwb3Mg YWRkZWQgdGhvdWdoKS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGUgYXV0aG9ycyB3 b3VsZCBsaWtlIHRoZSBESEMgV0cgdG8gY29uc2lkZXIgYWRvcHRpbmcgdGhpcyBkb2N1bWVudC48 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGFuayB5b3UhPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQom Z3Q7Jmd0OyBGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgRGF0ZTogVHVlLCBEZWMgMTAsIDIwMTkgYXQgMTA6NDQgQU08YnI+DQomZ3Q7Jmd0 OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLXY2 b25seS0wMS50eHQ8YnI+DQomZ3Q7Jmd0OyBUbzogVG9tZWsgTXJ1Z2Fsc2tpICZsdDs8YSBocmVm PSJtYWlsdG86dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50b21h c3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbTwvYT4mZ3Q7LCBMb3JlbnpvIENvbGl0dGkNCjxicj4NCiZn dDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDssIEplbiBMaW5rb3ZhICZsdDs8YSBocmVm PSJtYWlsdG86ZnVycnlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZ1cnJ5QGdvb2dsZS5j b208L2E+Jmd0OywgTWljaGFlbCBDLjxicj4NCiZndDsmZ3Q7IFJpY2hhcmRzb24gJmx0OzxhIGhy ZWY9Im1haWx0bzptY3IlMkJpZXRmQHNhbmRlbG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1jciYj NDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1saW5rLWRoYy12Nm9ubHktMDEudHh0IGhhcyBiZWVuIDxicj4NCiZndDsmZ3Q7IHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSmVuIExpbmtvdmEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiA8YnI+ DQomZ3Q7Jmd0OyByZXBvc2l0b3J5Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE5hbWU6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1saW5rLWRoYy12 Nm9ubHk8YnI+DQomZ3Q7Jmd0OyBSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsw MTxicj4NCiZndDsmZ3Q7IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SVB2Ni1Pbmx5LVByZWZlcnJlZCBPcHRpb24gZm9yIERIQ1A8YnI+DQomZ3Q7Jmd0OyBEb2N1bWVu dCBkYXRlOiZuYnNwOyAyMDE5LTEyLTA5PGJyPg0KJmd0OyZndDsgR3JvdXA6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7Jmd0 OyBQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEwPGJyPg0KJmd0OyZn dDsgVVJMOjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGluay1kaGMtdjZv bmx5LTAxLnR4dDwvYT48YnI+DQomZ3Q7Jmd0OyBTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWxpbmstZGhjLXY2b25seS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1saW5rLWRoYy12Nm9ubHkvPC9hPjxicj4NCiZndDsmZ3Q7IEh0 bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxPC9hPjxi cj4NCiZndDsmZ3Q7IEh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluay1kaGMtdjZv bmx5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1saW5rLWRoYy12Nm9ubHk8L2E+PGJyPg0KJmd0OyZndDsgRGlmZjombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGluay1kaGMtdjZvbmx5 LTAxPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgREhDUCBvcHRpb24gdG8g aW5kaWNhdGUgdGhhdCBhIGhvc3Q8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDtzdXBwb3J0cyBh biBJUHY2LW9ubHkgbW9kZSBhbmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4gSVB2NDxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2FkZHJlc3MgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXMg SVB2NiBjb25uZWN0aXZpdHkuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgPGJyPg0KJmd0OyZn dDsgc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsgU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJy eTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgZGhjd2cgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyBkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpkaGN3Z0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJy Pg0KRGF2aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1IiB0YXJn ZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48YnI+DQpOZXR3b3JraW5nICZh bXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyPg0KT2ZmaWNlIG9mIEluZm9ybWF0aW9u IFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJzaXR5IG9mIE1pbm5lc290YSZuYnNwOyZuYnNwOyA8YnI+ DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBob25l OiA2MTItNjI2LTA4MTU8YnI+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSZuYnNwOyZuYnNw OyBDZWxsOiA2MTItODEyLTk5NTI8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F6B54CA9BCF94E2CB431AC73954C99AEciscocom_-- From nobody Tue Dec 10 10:21:21 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CEF120A28 for ; Tue, 10 Dec 2019 10:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cSxommcmYHhC for ; Tue, 10 Dec 2019 10:21:14 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38038120A27 for ; Tue, 10 Dec 2019 10:21:14 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id h14so228013pfe.10 for ; Tue, 10 Dec 2019 10:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eIOD32da2x5iu3Q3jtEHUQcqt484s7sv1Ry/PdL/Dyg=; b=aD/8JTm4gWsUo10JEvXi7tBGOe0OhE3NlLNe/MS8YY3GE1o9qdL3vT9YmdfXrvLmcC oo459c1/ff4VWGUQXuJFypOaRETCnTHAAkcxVr7Pqau+m9+tRNgyQN1lEMlApfA46+xo KDmG7sRLZ3M8TtDncbADUIYVGWgRkQlYVKy2BG5JVZZ8YtaeORlfcMbbVpgfyawnSPbr ys08BxMdc7sY2YZpc5NF1Dz/x4tVHvF3HFnI5iQjxRRLj/dE9M56sDt7j1HVrMbJPlU6 vV+h8Pkqsd8cu4Q2cs8/lWBx7gp9BffyGrmEywvVCtPP/0PZcb5V5XqQsP8Ae8YsHcQM /K5Q== 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=eIOD32da2x5iu3Q3jtEHUQcqt484s7sv1Ry/PdL/Dyg=; b=iswTBr5/J39uYw/IwaVBmJXwq65THIUFE//w37PfKBCzN1lSnouccG429m2safoieU VmnlAGGA/mlm0/ikWU/QYY8Bn320p6Gp59cY6awVbWia4lemN6mGbqPvCG/746UWaJnL dVltJJ2M3HMbHNsfZA2invQydkL1n++AT3Pe1wz/7DrllCeaJsLZzqFOKbQ7OTdHGULR 0g7uC2iTJ3dzme49mdFANcz5ChJZZtRBwlNgnieP0ZwnmXiJhGA5ppeTXTeD1l+X8GOv z5QornYfc5Tifasge+kTsVsW5JaX+C44Kmgt2H3ZWpL9oTroxn5SV9n50tt4ETmIp7rT ym9Q== X-Gm-Message-State: APjAAAVnivZRCSj36QM9X7U5IAh26zr0/ZG1ZrcnpzUDUd9Bb/WQV/PL oIDWa/XiAVouWLO5P2VCTM4nUyTUSGU= X-Google-Smtp-Source: APXvYqwGDskuuVWGXHApjT50WX9+6eUUnfR5/vKVFSvlNlUtDAPIE3H22K+wJL2GSMFXSlAmExYuPA== X-Received: by 2002:a63:fd10:: with SMTP id d16mr25712872pgh.177.1576002073610; Tue, 10 Dec 2019 10:21:13 -0800 (PST) Received: from [17.192.139.178] ([17.192.139.178]) by smtp.gmail.com with ESMTPSA id e11sm3510553pjj.26.2019.12.10.10.21.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 10:21:12 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D0082AA3-1CC3-4E28-9966-19723BB1CC63" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Tue, 10 Dec 2019 10:21:11 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153707127@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , V6 Ops List To: "STARK, BARBARA H" References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61153707127@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 18:21:17 -0000 --Apple-Mail=_D0082AA3-1CC3-4E28-9966-19723BB1CC63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 10, 2019, at 9:16 AM, STARK, BARBARA H wrote: > Some CE routers are coded to have special handling for 0.0.0.0. = Multiple ISPs use that address for IPTV multicast traffic (on a VLAN = dedicated to that traffic). I could envision such routers having issues = with getting 0.0.0.0 from DHCPv4. CE router vendors and their chipset = vendors do the darnedest things sometimes (as Cloudflare discovered wrt = 1.1.1.1). I think widespread testing of CE routers is needed if the = returned address is going to be required to 0.0.0.0.=20 The idea here is that the returned address is bogus and won=E2=80=99t = work. So if the CE router tries to use it for anything, it=E2=80=99s = going to break, whether it=E2=80=99s 0.0.0.0 or 192.0.0.0. > Here is language from BBF TR-124 (requirement LAN.IGMP.ROUTED): "It = MUST be possible to configure a WAN-facing IPv4 interface with an IPoE = encapsulation and no IPv4 address visible by the access network. It MUST = be possible to receive multicast traffic on such an interface, = independent of whether upstream IGMP is sent on this interface or not. = The RG's IGMP proxy-routing function MUST be able to send upstream IGMP = traffic on such an interface, using an unspecified (0.0.0.0/::) IPv4 = source address.=E2=80=9D I don=E2=80=99t think this would be violated. Is DHCPv4 currently = configuring an address of 0.0.0.0 for IGMP to use? :) --Apple-Mail=_D0082AA3-1CC3-4E28-9966-19723BB1CC63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 10, 2019, at 9:16 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
Some CE = routers are coded to have special handling for 0.0.0.0. Multiple ISPs = use that address for IPTV multicast traffic (on a VLAN dedicated to that = traffic). I could envision such routers having issues with getting = 0.0.0.0 from DHCPv4. CE router vendors and their chipset vendors do the = darnedest things sometimes (as Cloudflare discovered wrt 1.1.1.1). =  I think widespread testing of CE routers is needed if the returned = address is going to be required to 0.0.0.0. 

The idea = here is that the returned address is bogus and won=E2=80=99t work. =   So if the CE router tries to use it for anything, it=E2=80=99s = going to break, whether it=E2=80=99s 0.0.0.0 or 192.0.0.0.

Here is = language from BBF TR-124 (requirement LAN.IGMP.ROUTED): "It MUST be = possible to configure a WAN-facing IPv4 interface with an IPoE = encapsulation and no IPv4 address visible by the access network. It MUST = be possible to receive multicast traffic on such an interface, = independent of whether upstream IGMP is sent on this interface or not. = The RG's IGMP proxy-routing function MUST be able to send upstream IGMP = traffic on such an interface, using an unspecified (0.0.0.0/::) IPv4 = source address.=E2=80=9D

I don=E2=80=99t think this would be = violated.   Is DHCPv4 currently configuring an address of 0.0.0.0 = for IGMP to use?  :)


= --Apple-Mail=_D0082AA3-1CC3-4E28-9966-19723BB1CC63-- From nobody Tue Dec 10 11:41:45 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634A8120A19; Tue, 10 Dec 2019 11:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 oMKHSway3BUy; Tue, 10 Dec 2019 11:41:36 -0800 (PST) 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 3DBA51208BF; Tue, 10 Dec 2019 11:41:36 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBAJaAr1010562; Tue, 10 Dec 2019 14:41:32 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2wthn789ae-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 14:41:28 -0500 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 xBAJfNC0001120; Tue, 10 Dec 2019 14:41:24 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xBAJfI3u000908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Dec 2019 14:41:18 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 3AC80400AF94; Tue, 10 Dec 2019 19:41:18 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30485.vci.att.com (Service) with ESMTPS id 248B5400AE35; Tue, 10 Dec 2019 19:41:18 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 14:41:11 -0500 From: "STARK, BARBARA H" To: "'Ted Lemon'" CC: "'Bernie Volz (volz)'" , "'dhcwg@ietf.org'" , "'V6 Ops List'" Thread-Topic: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3hrvkTFCkrF9EyvHpagg10RDKezlNZQgABtPYD//7x3oA== Date: Tue, 10 Dec 2019 19:41:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153708DD1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61153707127@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.215.132] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61153708DD1GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-10_06:2019-12-10,2019-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 clxscore=1015 impostorscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912100161 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 19:41:38 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61153708DD1GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KDQpPbiBEZWMgMTAsIDIwMTksIGF0 IDk6MTYgQU0sIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJA YXR0LmNvbT4+IHdyb3RlOg0KU29tZSBDRSByb3V0ZXJzIGFyZSBjb2RlZCB0byBoYXZlIHNwZWNp YWwgaGFuZGxpbmcgZm9yIDAuMC4wLjAuIE11bHRpcGxlIElTUHMgdXNlIHRoYXQgYWRkcmVzcyBm b3IgSVBUViBtdWx0aWNhc3QgdHJhZmZpYyAob24gYSBWTEFOIGRlZGljYXRlZCB0byB0aGF0IHRy YWZmaWMpLiBJIGNvdWxkIGVudmlzaW9uIHN1Y2ggcm91dGVycyBoYXZpbmcgaXNzdWVzIHdpdGgg Z2V0dGluZyAwLjAuMC4wIGZyb20gREhDUHY0LiBDRSByb3V0ZXIgdmVuZG9ycyBhbmQgdGhlaXIg Y2hpcHNldCB2ZW5kb3JzIGRvIHRoZSBkYXJuZWRlc3QgdGhpbmdzIHNvbWV0aW1lcyAoYXMgQ2xv dWRmbGFyZSBkaXNjb3ZlcmVkIHdydCAxLjEuMS4xKS4gIEkgdGhpbmsgd2lkZXNwcmVhZCB0ZXN0 aW5nIG9mIENFIHJvdXRlcnMgaXMgbmVlZGVkIGlmIHRoZSByZXR1cm5lZCBhZGRyZXNzIGlzIGdv aW5nIHRvIGJlIHJlcXVpcmVkIHRvIDAuMC4wLjAuDQoNClRoZSBpZGVhIGhlcmUgaXMgdGhhdCB0 aGUgcmV0dXJuZWQgYWRkcmVzcyBpcyBib2d1cyBhbmQgd29u4oCZdCB3b3JrLiAgIFNvIGlmIHRo ZSBDRSByb3V0ZXIgdHJpZXMgdG8gdXNlIGl0IGZvciBhbnl0aGluZywgaXTigJlzIGdvaW5nIHRv IGJyZWFrLCB3aGV0aGVyIGl04oCZcyAwLjAuMC4wIG9yIDE5Mi4wLjAuMC4NCg0KQ29uc2lkZXIg dGhlIHBvc3NpYmlsaXR5IG9mIGEgQ0Ugcm91dGVyIHRoYXQgc2F5czog4oCcUHJvcGVyIERIQ1Ag c2VydmVycyBkb27igJl0IHNlbmQgYm9ndXMgYWRkcmVzc2VzLiBJ4oCZbSByZWNlaXZpbmcgYSBi b2d1cyBhZGRyZXNzIGZyb20gdGhpcyBESENQIHNlcnZlci4gVGhhdCBtZWFucyB0aGlzIERIQ1Ag c2VydmVyIG11c3QgYmUgY29tcHJvbWlzZWQsIHdoaWNoIG1lYW5zIHRoZSBuZXR3b3JrIGlzIGNv bXByb21pc2VkLCB3aGljaCBtZWFucyBJIGNhbiB0cnVzdCBub3RoaW5nIG9uIHRoaXMgbmV0d29y ay4gSSBzaGFsbCBub3cgKGNob2ljZSBBKSBjZWFzZSBhbGwgY29tbXVuaWNhdGlvbiB3aXRoIHRo aXMgbmV0d29yazsgKG9yIGNob2ljZSBCKSBjb250aW51ZSB0byBzZW5kIERIQ1B2NCBtZXNzYWdl cyBmcmVxdWVudGx5IHVudGlsIEkgZ2V0IG9uZSB0aGF0IGhhcyBhIG5vbi1ib2d1cyBhZGRyZXNz LuKAnSBXZSBqdXN0IGRvbuKAmXQga25vdy4gV2UgaGFkIG5vIGlkZWEgdGhhdCB0aGVyZSB3ZXJl IGNoaXBzZXRzIGluIHJvdXRlcnMgd2l0aCBjaGlwc2V0IGZpcm13YXJlIHRoYXQgY29uc2lkZXJl ZCBtZXNzYWdlcyB0by9mcm9tIDEuMS4xLjEgYSB0aHJlYXQgYW5kIGEgc2VjdXJpdHkgdmlvbGF0 aW9uLiBJdOKAmXMgaW1wb3J0YW50IG5vdCB0byBhc3N1bWUgdGhhdCByb3V0ZXJzIGFyZSB0b2xl cmFudCBvZiAwLjAuMC4wIGluIERIQ1AgcmVzcG9uc2VzLiBJIHRoaW5rIHdob2V2ZXIgd2FudHMg MC4wLjAuMCBtYW5kYXRlZCBvciBwcmVmZXJyZWQgbmVlZHMgdG8gYmUgdGhlIG9uZSB0byBwcm92 ZSB0aGF0IGl0IHdvdWxkIG5vdCBjYXVzZSBoYXJtLCBiZWNhdXNlIEnigJltIG5vdCBzZWVpbmcg ZXZpZGVuY2Ugb2YgcmVhbCBiZW5lZml0IG9mIHN1Y2ggbm9ybWF0aXZlIGxhbmd1YWdlLiBJZiB0 aGUgSVAgYWRkcmVzcyhlcykgdG8gcmV0dXJuIGFyZSBsZWZ0IHVwIHRvIHRoZSBkZXBsb3llciwg dGhlbiB0aGUgZGVwbG95ZXIgY2FuIG1ha2Ugc3VyZSB3aGF0ZXZlciB0aGV5IGRvIHdvcmtzIGlu IHRoZWlyIG5ldHdvcmssIHdpdGggdGhlaXIgc2VydmVyIGFuZCBtaWRkbGVib3hlcyBhbmQgd2hh dGV2ZXIgY2xpZW50cyBhcmUgYXR0YWNoaW5nLiBbQlRXLCBUZWQsIEnigJltIGhhdmluZyB0byBj aGFuZ2UgbXkgZW1haWwgY2xpZW50IHNldHRpbmdzIGV2ZXJ5IHRpbWUgdG8gaGF2ZSBkaWZmZXJl bnQgcnVsZXMgZm9yIHJlc3BvbnNlcyB0byB0ZXh0IHZzLiBodG1sL3JpY2ggdGV4dCDigJMgdGhp cyBpcyBJRVRGLCBkYXJuIGl0LCBzbyB3ZSBzaG91bGQgYWxsIGJlIHVzaW5nIHBsYWluIHRleHQ7 IHBlcnNvbmFsIGV4cGVyaW1lbnQgb3ZlcjsgcnVsZXMgZmF2b3JpbmcgcGxhaW4gdGV4dCBhcmUg c3RheWluZyBhbmQgbm8gbW9yZSBzd2l0Y2hpbmcgb3B0aW9ucyB0byBzYXRpc2Z5IHBlb3BsZSB3 aG8gZG9u4oCZdCByZXBseSB0byB0ZXh0IHdpdGggdGV4dC5dDQoNCkhlcmUgaXMgbGFuZ3VhZ2Ug ZnJvbSBCQkYgVFItMTI0IChyZXF1aXJlbWVudCBMQU4uSUdNUC5ST1VURUQpOiAiSXQgTVVTVCBi ZSBwb3NzaWJsZSB0byBjb25maWd1cmUgYSBXQU4tZmFjaW5nIElQdjQgaW50ZXJmYWNlIHdpdGgg YW4gSVBvRSBlbmNhcHN1bGF0aW9uIGFuZCBubyBJUHY0IGFkZHJlc3MgdmlzaWJsZSBieSB0aGUg YWNjZXNzIG5ldHdvcmsuIEl0IE1VU1QgYmUgcG9zc2libGUgdG8gcmVjZWl2ZSBtdWx0aWNhc3Qg dHJhZmZpYyBvbiBzdWNoIGFuIGludGVyZmFjZSwgaW5kZXBlbmRlbnQgb2Ygd2hldGhlciB1cHN0 cmVhbSBJR01QIGlzIHNlbnQgb24gdGhpcyBpbnRlcmZhY2Ugb3Igbm90LiBUaGUgUkcncyBJR01Q IHByb3h5LXJvdXRpbmcgZnVuY3Rpb24gTVVTVCBiZSBhYmxlIHRvIHNlbmQgdXBzdHJlYW0gSUdN UCB0cmFmZmljIG9uIHN1Y2ggYW4gaW50ZXJmYWNlLCB1c2luZyBhbiB1bnNwZWNpZmllZCAoMC4w LjAuMC86OikgSVB2NCBzb3VyY2UgYWRkcmVzcy7igJ0NCg0KSSBkb27igJl0IHRoaW5rIHRoaXMg d291bGQgYmUgdmlvbGF0ZWQuICAgSXMgREhDUHY0IGN1cnJlbnRseSBjb25maWd1cmluZyBhbiBh ZGRyZXNzIG9mIDAuMC4wLjAgZm9yIElHTVAgdG8gdXNlPyAgOikNCg0KDQo= --_000_2D09D61DDFA73D4C884805CC7865E61153708DD1GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1z cGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+RnJvbTo8L2I+IFRlZCBM ZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNvbSZndDsNCjxicj4NCjxicj4NCjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBEZWMgMTAsIDIwMTksIGF0 IDk6MTYgQU0sIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0 LmNvbSI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVn dWxhciZxdW90OyxzZXJpZiI+U29tZSBDRSByb3V0ZXJzIGFyZSBjb2RlZCB0byBoYXZlIHNwZWNp YWwgaGFuZGxpbmcgZm9yIDAuMC4wLjAuIE11bHRpcGxlIElTUHMgdXNlIHRoYXQgYWRkcmVzcyBm b3IgSVBUViBtdWx0aWNhc3QgdHJhZmZpYyAob24gYSBWTEFOIGRlZGljYXRlZCB0bw0KIHRoYXQg dHJhZmZpYykuIEkgY291bGQgZW52aXNpb24gc3VjaCByb3V0ZXJzIGhhdmluZyBpc3N1ZXMgd2l0 aCBnZXR0aW5nIDAuMC4wLjAgZnJvbSBESENQdjQuIENFIHJvdXRlciB2ZW5kb3JzIGFuZCB0aGVp ciBjaGlwc2V0IHZlbmRvcnMgZG8gdGhlIGRhcm5lZGVzdCB0aGluZ3Mgc29tZXRpbWVzIChhcyBD bG91ZGZsYXJlIGRpc2NvdmVyZWQgd3J0IDEuMS4xLjEpLiAmbmJzcDtJIHRoaW5rIHdpZGVzcHJl YWQgdGVzdGluZyBvZiBDRSByb3V0ZXJzIGlzDQogbmVlZGVkIGlmIHRoZSByZXR1cm5lZCBhZGRy ZXNzIGlzIGdvaW5nIHRvIGJlIHJlcXVpcmVkIHRvIDAuMC4wLjAuPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBpZGVhIGhlcmUgaXMgdGhh dCB0aGUgcmV0dXJuZWQgYWRkcmVzcyBpcyBib2d1cyBhbmQgd29u4oCZdCB3b3JrLiAmbmJzcDsg U28gaWYgdGhlIENFIHJvdXRlciB0cmllcyB0byB1c2UgaXQgZm9yIGFueXRoaW5nLCBpdOKAmXMg Z29pbmcgdG8gYnJlYWssIHdoZXRoZXIgaXTigJlzIDAuMC4wLjAgb3IgMTkyLjAuMC4wLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zaWRlciB0aGUgcG9zc2liaWxp dHkgb2YgYSBDRSByb3V0ZXIgdGhhdCBzYXlzOiDigJxQcm9wZXIgREhDUCBzZXJ2ZXJzIGRvbuKA mXQgc2VuZCBib2d1cyBhZGRyZXNzZXMuIEnigJltIHJlY2VpdmluZyBhIGJvZ3VzIGFkZHJlc3Mg ZnJvbSB0aGlzIERIQ1Agc2VydmVyLiBUaGF0IG1lYW5zIHRoaXMgREhDUCBzZXJ2ZXIgbXVzdCBi ZSBjb21wcm9taXNlZCwgd2hpY2ggbWVhbnMgdGhlIG5ldHdvcmsgaXMgY29tcHJvbWlzZWQsDQog d2hpY2ggbWVhbnMgSSBjYW4gdHJ1c3Qgbm90aGluZyBvbiB0aGlzIG5ldHdvcmsuIEkgc2hhbGwg bm93IChjaG9pY2UgQSkgY2Vhc2UgYWxsIGNvbW11bmljYXRpb24gd2l0aCB0aGlzIG5ldHdvcms7 IChvciBjaG9pY2UgQikgY29udGludWUgdG8gc2VuZCBESENQdjQgbWVzc2FnZXMgZnJlcXVlbnRs eSB1bnRpbCBJIGdldCBvbmUgdGhhdCBoYXMgYSBub24tYm9ndXMgYWRkcmVzcy7igJ0gV2UganVz dCBkb27igJl0IGtub3cuIFdlIGhhZCBubyBpZGVhIHRoYXQNCiB0aGVyZSB3ZXJlIGNoaXBzZXRz IGluIHJvdXRlcnMgd2l0aCBjaGlwc2V0IGZpcm13YXJlIHRoYXQgY29uc2lkZXJlZCBtZXNzYWdl cyB0by9mcm9tIDEuMS4xLjEgYSB0aHJlYXQgYW5kIGEgc2VjdXJpdHkgdmlvbGF0aW9uLiBJdOKA mXMgaW1wb3J0YW50IG5vdCB0byBhc3N1bWUgdGhhdCByb3V0ZXJzIGFyZSB0b2xlcmFudCBvZiAw LjAuMC4wIGluIERIQ1AgcmVzcG9uc2VzLiBJIHRoaW5rIHdob2V2ZXIgd2FudHMgMC4wLjAuMCBt YW5kYXRlZCBvcg0KIHByZWZlcnJlZCBuZWVkcyB0byBiZSB0aGUgb25lIHRvIHByb3ZlIHRoYXQg aXQgd291bGQgbm90IGNhdXNlIGhhcm0sIGJlY2F1c2UgSeKAmW0gbm90IHNlZWluZyBldmlkZW5j ZSBvZiByZWFsIGJlbmVmaXQgb2Ygc3VjaCBub3JtYXRpdmUgbGFuZ3VhZ2UuIElmIHRoZSBJUCBh ZGRyZXNzKGVzKSB0byByZXR1cm4gYXJlIGxlZnQgdXAgdG8gdGhlIGRlcGxveWVyLCB0aGVuIHRo ZSBkZXBsb3llciBjYW4gbWFrZSBzdXJlIHdoYXRldmVyIHRoZXkgZG8gd29ya3MNCiBpbiB0aGVp ciBuZXR3b3JrLCB3aXRoIHRoZWlyIHNlcnZlciBhbmQgbWlkZGxlYm94ZXMgYW5kIHdoYXRldmVy IGNsaWVudHMgYXJlIGF0dGFjaGluZy4gW0JUVywgVGVkLCBJ4oCZbSBoYXZpbmcgdG8gY2hhbmdl IG15IGVtYWlsIGNsaWVudCBzZXR0aW5ncyBldmVyeSB0aW1lIHRvIGhhdmUgZGlmZmVyZW50IHJ1 bGVzIGZvciByZXNwb25zZXMgdG8gdGV4dCB2cy4gaHRtbC9yaWNoIHRleHQg4oCTIHRoaXMgaXMg SUVURiwgZGFybiBpdCwgc28gd2Ugc2hvdWxkDQogYWxsIGJlIHVzaW5nIHBsYWluIHRleHQ7IHBl cnNvbmFsIGV4cGVyaW1lbnQgb3ZlcjsgcnVsZXMgZmF2b3JpbmcgcGxhaW4gdGV4dCBhcmUgc3Rh eWluZyBhbmQgbm8gbW9yZSBzd2l0Y2hpbmcgb3B0aW9ucyB0byBzYXRpc2Z5IHBlb3BsZSB3aG8g ZG9u4oCZdCByZXBseSB0byB0ZXh0IHdpdGggdGV4dC5dPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5IZXJl IGlzIGxhbmd1YWdlIGZyb20gQkJGIFRSLTEyNCAocmVxdWlyZW1lbnQgTEFOLklHTVAuUk9VVEVE KTogJnF1b3Q7SXQgTVVTVCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgYSBXQU4tZmFjaW5nIElQ djQgaW50ZXJmYWNlIHdpdGggYW4gSVBvRSBlbmNhcHN1bGF0aW9uDQogYW5kIG5vIElQdjQgYWRk cmVzcyB2aXNpYmxlIGJ5IHRoZSBhY2Nlc3MgbmV0d29yay4gSXQgTVVTVCBiZSBwb3NzaWJsZSB0 byByZWNlaXZlIG11bHRpY2FzdCB0cmFmZmljIG9uIHN1Y2ggYW4gaW50ZXJmYWNlLCBpbmRlcGVu ZGVudCBvZiB3aGV0aGVyIHVwc3RyZWFtIElHTVAgaXMgc2VudCBvbiB0aGlzIGludGVyZmFjZSBv ciBub3QuIFRoZSBSRydzIElHTVAgcHJveHktcm91dGluZyBmdW5jdGlvbiBNVVNUIGJlIGFibGUg dG8gc2VuZCB1cHN0cmVhbQ0KIElHTVAgdHJhZmZpYyBvbiBzdWNoIGFuIGludGVyZmFjZSwgdXNp bmcgYW4gdW5zcGVjaWZpZWQgKDAuMC4wLjAvOjopIElQdjQgc291cmNlIGFkZHJlc3Mu4oCdPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5JIGRvbuKAmXQgdGhpbmsgdGhpcyB3b3VsZCBiZSB2aW9sYXRlZC4gJm5ic3A7 IElzIERIQ1B2NCBjdXJyZW50bHkgY29uZmlndXJpbmcgYW4gYWRkcmVzcyBvZiAwLjAuMC4wIGZv ciBJR01QIHRvIHVzZT8gJm5ic3A7Oik8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E61153708DD1GAALPA1MSGUSRBF_-- From nobody Tue Dec 10 11:44:28 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341D21208BF for ; Tue, 10 Dec 2019 11:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsPYU-7ZGp2d for ; Tue, 10 Dec 2019 11:44:25 -0800 (PST) Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385BD120A49 for ; Tue, 10 Dec 2019 11:44:25 -0800 (PST) Received: by mail-pj1-x1042.google.com with SMTP id g4so7790723pjs.10 for ; Tue, 10 Dec 2019 11:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UIa8yXyqaX5EA3qski/f87ySMu1gsvFhBr9sdvjF7J8=; b=itCrDN9Dsgm+TUVZ862Hgvwi/UveymmpkG2c9nadHKbuEgDw8esbsBOx7VXka31ivh Bhk4s4xyyAT6Lts0zMS+93K9FgaPWFdsPJgoLk8pBej1rd0nRqCYzvqULzrW1QfdKiZp LqB6RoToOtGkadN/mcKJ7rFq1qoZUkZv4i81w6wWW7CVf80s2T4v2v2Y5eLrDfekbl/t rk/xDbLMnW9ihR1A+tysqI5kguOlb8jlcVS+Rz2XbF/bzq8ta3XMBj6cLd6rnph3gYOf s431rauTD//mgOQnxaSE5YJ5DCb5IHll7A18t7MTdlJU54eI2MlQGKzJglh6sd9cc3vo 2Utg== 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=UIa8yXyqaX5EA3qski/f87ySMu1gsvFhBr9sdvjF7J8=; b=UGpK0WdOstsTNVxz+qldyxQj3zYyfcC+P9rVKuTysHgkx9Bh4c/aitwgF67zHqk+qW oPYXuCQ5suP/WHXg8cmUiigHKCpy/ltX5ohZn0L4YdeeKGHdfYPLloG50qTTL7tbENrv 0TFFeVGKZ03xXUGe/BQ+NOpLYPy8eoMppHMRRakua2cqJddjL5RqEee8hKXHA5srYVcd dYP/eUwpMGjVCs1POm4LojFBJ9AfOpw0p/4A+sDwNNyIIytATMJLFcP3K1ORlgK8Mln7 tN5ous9d5lI3JmFso5wPCorNlAsTuWJNLdQvD/ZSiSn4CmhayLZczvFyvKEFoU/IUa8s zQ7Q== X-Gm-Message-State: APjAAAU66LJZHV48s7f7ZVnl2CWDe/GIl2ddE37OmsfeOBJnW2Ks+Exx VffWZ14d1IwUA9tJRWVIppInV/hTA+A= X-Google-Smtp-Source: APXvYqzIK1NOxs8+IS3bEfXI6qgeYnxhhtXXIKM9wVaxVyI0IKDF36Ep4emNRH1DjYlGEnMt4cczrw== X-Received: by 2002:a17:902:27:: with SMTP id 36mr12103473pla.270.1576007064632; Tue, 10 Dec 2019 11:44:24 -0800 (PST) Received: from [17.192.139.178] ([17.192.139.178]) by smtp.gmail.com with ESMTPSA id l18sm4435213pff.79.2019.12.10.11.44.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2019 11:44:23 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_64D7FB4E-6088-4B81-ABAC-8C3553103E53" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Tue, 10 Dec 2019 11:44:22 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153708DD1@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" , V6 Ops List To: "STARK, BARBARA H" References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E61153707127@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61153708DD1@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 19:44:27 -0000 --Apple-Mail=_64D7FB4E-6088-4B81-ABAC-8C3553103E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 10, 2019, at 11:41 AM, STARK, BARBARA H wrote: > Consider the possibility of a CE router that says: =E2=80=9CProper = DHCP servers don=E2=80=99t send bogus addresses. I=E2=80=99m receiving a = bogus address from this DHCP server. That means this DHCP server must be = compromised, which means the network is compromised, which means I can = trust nothing on this network.=20 That DHCP client would be a DHCP client that doesn=E2=80=99t implement = the specification, since the specification would say MUST accept = yiaddr=3D0.0.0.0 when in v6-only mode. That client would not be asking = for the v6-only option, and hence would never see a yiaddr of 0.0.0.0. --Apple-Mail=_64D7FB4E-6088-4B81-ABAC-8C3553103E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 10, 2019, at 11:41 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
Consider the = possibility of a CE router that says: =E2=80=9CProper DHCP servers = don=E2=80=99t send bogus addresses. I=E2=80=99m receiving a bogus = address from this DHCP server. That means this DHCP server must be = compromised, which means the network is compromised, which means I can = trust nothing on this network. 

That DHCP client would be a DHCP = client that doesn=E2=80=99t implement the specification, since the = specification would say MUST accept yiaddr=3D0.0.0.0 when in v6-only = mode.   That client would not be asking for the v6-only option, and = hence would never see a yiaddr of 0.0.0.0.

= --Apple-Mail=_64D7FB4E-6088-4B81-ABAC-8C3553103E53-- From nobody Tue Dec 10 14:13:57 2019 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 28AE91200D7; Tue, 10 Dec 2019 14:13:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <157601603005.9927.7692547024710893156@ietfa.amsl.com> Date: Tue, 10 Dec 2019 14:13:50 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nd-cache-init-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 22:13:50 -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 : Neighbor Cache Entries on First-Hop Routers: Operational Considerations Author : Jen Linkova Filename : draft-ietf-v6ops-nd-cache-init-01.txt Pages : 11 Date : 2019-12-10 Abstract: Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document discusses how the neighbor discovery state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nd-cache-init-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 10 14:21:46 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B7112018D; Tue, 10 Dec 2019 14:21:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnTHFMp83PHW; Tue, 10 Dec 2019 14:21:43 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB401200D7; Tue, 10 Dec 2019 14:21:43 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id 5so4382493qtz.1; Tue, 10 Dec 2019 14:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJJ4Ez0+wp7o9eaRk9rAHneMANUHEpNcTt5gApi02Lo=; b=jKhJ3zNa0m1mpqbl5XyNPIDbH70GEOEHebXex15JOe7i+U3QFflGa/PWixXyjdTcYo ptUsp6pe3M8uilPHhPDVsE8THtLtEz2HQZNHANfibFrb/KbYl9lxpIq/lSKTIwKaYA1y 6bLpO0Bdsr4raeivjRKg7n14kzD3dfGrqc0RR//Nb+zCJsOMJLGP3oh2bfSkf+xLgZft tXPvBYWvy9KrmQ/QEpO5jLYs+4u5pKFFWHrFbrWweuCEysV9OsQahhZvgOns+lfrlTxL m4uz5B94GSgl/9HcCnwm3YspjdaLofseNU0FGcZA57V0NkU/3rargZFtq4Nk3Lmm4HPt 2USA== 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=nJJ4Ez0+wp7o9eaRk9rAHneMANUHEpNcTt5gApi02Lo=; b=RIUxhiaLaVJ72rSB141bpy9VQxMtmo7y864EMXwNoj89vlQmqDDooHtxQQxvL3MkRg 7sXmhwT3PLKwBkYSZSu6ykiMbnkLNKf73QHPKmDc2J+r9dEVDqM6V1aQfDER7OOaSRA8 2VOaVTeRO+07e4e6Ml3EyvQph/kJPPhsdByK8R6DHyCJXbJ2OiGXegq8NaRse0HpKqan M+fXB0Fsw2j/licHyNQz3P2GoEaZVkdUk5qxwrdKKQIoORrC5YixSSM6tMIAnWCX4LPo k4QPAuBiSGeHcR0JJX+td5+x79C8+kpfkPdu4hzT84PpziXc2cxQDp/e0VeLWsxUX6Lb BCZg== X-Gm-Message-State: APjAAAVyX3usX1G2llPRxIitQKJ9A+7e1c34O8VPNCdNzUa3WoW3Vcc1 3UyXROUlN402MAZjPu8wVckAX1ZuZOZVfx9fsCemIZX8 X-Google-Smtp-Source: APXvYqzMHYMvFPSbu/90iC5Ajr3djcVSZ3lGdruAxjab7sxRQFOxawVDNsAYEnvNazF3E64yCvoKv4174L3jM8F4WjE= X-Received: by 2002:ac8:5313:: with SMTP id t19mr156552qtn.118.1576016501999; Tue, 10 Dec 2019 14:21:41 -0800 (PST) MIME-Version: 1.0 References: <157601603005.9927.7692547024710893156@ietfa.amsl.com> In-Reply-To: <157601603005.9927.7692547024710893156@ietfa.amsl.com> From: Jen Linkova Date: Wed, 11 Dec 2019 09:21:30 +1100 Message-ID: To: V6 Ops List Cc: i-d-announce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nd-cache-init-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 22:21:45 -0000 The main changes in -01 are based on what Dave Thaler said at the mic at IETF106: 1) the possible solutions list is updated with 'dataplane packets from new addresses triggers address resolution'. 2) all approaches ex. the one suggested are moved to a dedicated section, 'Solutions Considered but Discarded'. Dave, I know you think we shall completely remove that text but IMHO it would be beneficial to have Cons documented - especially taking into account some vendor have implemented those features already. (I also forgot to mention you in the Ack section and that will be fixed in -02 ;) On Wed, Dec 11, 2019 at 9:14 AM 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 : Neighbor Cache Entries on First-Hop Routers: Operational Considerations > Author : Jen Linkova > Filename : draft-ietf-v6ops-nd-cache-init-01.txt > Pages : 11 > Date : 2019-12-10 > > Abstract: > Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the > link-layer addresses of neighboring nodes as well as to discover and > maintain reachability information. This document discusses how the > neighbor discovery state machine on a first-hop router is causing > user-visible connectivity issues when a new (not being seen on the > network before) IPv6 address is being used. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-nd-cache-init-01 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nd-cache-init-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- SY, Jen Linkova aka Furry From nobody Tue Dec 10 22:28:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0250E1201DC; Tue, 10 Dec 2019 22:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlqL4T6pNkbE; Tue, 10 Dec 2019 22:28:20 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B019120154; Tue, 10 Dec 2019 22:28:20 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 47Xn765p6KzCs2V; Wed, 11 Dec 2019 07:28:18 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 47Xn765C1hz1xpS; Wed, 11 Dec 2019 07:28:18 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 11 Dec 2019 07:28:18 +0100 From: To: "Bernie Volz (volz)" , Jen Linkova , "dhcwg@ietf.org" CC: V6 Ops List Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKe0c/9w Date: Wed, 11 Dec 2019 06:28:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 06:28:23 -0000 Hi Bernie,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Bernie Volz (volz) [mailto:volz@cisco.com] > Envoy=E9=A0: mardi 10 d=E9cembre 2019 17:11 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; Jen Linkova; dhcwg@ietf.org > Cc=A0: V6 Ops List > Objet=A0: RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc- > v6only-01.txt >=20 > Hi: >=20 > Is (8): >=20 > (8) Consider returning an address from the range defined in RFC7335 > for IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv= 6- > only hosts (those with a CLAT for example). >=20 > =3D=3D=3D=3D > The result is that 192.0.0.0/29 may be used in any system > that requires IPv4 addresses for backward compatibility with IPv4 > communications in an IPv6-only network but does not emit IPv4 > packets > "on the wire". > =3D=3D=3D=3D >=20 > But RFC7335 says (in section 4): >=20 > IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], > which is dedicated for DS-Lite. As defined in [RFC6333], this subnet > is only present between the B4 and the Address Family Transition > Router (AFTR) and never emits packets from this prefix "on the wire". > <--- > 464XLAT has the same need for a non-routed IPv4 prefix, and this same > need may be common for other similar solutions. It is most prudent > and effective to generalize 192.0.0.0/29 for the use of supporting > IPv4 interfaces in IPv6 transition technologies rather than reserving > a prefix for every possible solution. >=20 > So, this address is only used "on the host" (not on the wire), so why wou= ld > there be any need for the DHCP server to assign this address? [Med] This is to ease remote troubleshooting of the IPv4aaS component (CLAT= , B4) of the IPv6-only host. Controlling the IPv4 address configured locall= y allows to make use of tools such as PROBE (https://tools.ietf.org/html/rf= c8335) to remotely assess the status of the IPv4aaS component via an IPv6 n= etwork. >=20 > And as the IPv6-only option means that the host never completes the > DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be > used to assign any address. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg On Behalf Of > mohamed.boucadair@orange.com > Sent: Tuesday, December 10, 2019 5:32 AM > To: Jen Linkova ; dhcwg@ietf.org > Cc: V6 Ops List > Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc- > v6only-01.txt >=20 > Hi Jen, >=20 > Thank you for sharing this updated version. Below some points that I do > think need more clarification in the I-D: >=20 > (1) The document is too NAT64 centric. The proposal may apply as well for > other IPv6-only deployment scenarios (typically, unmanaged IPv6-only CPEs > with IPv4aaS). >=20 > (2) A discussion on the benefit of this extra signal compared to relying = on > existing signals (pref64, aftr_name, map_container...). For example, a ho= st > that supports the option is ready to wait at minimum 300s and disable its > IPv4 configuration regardless of what is happening on the IPv6 leg. How i= s > that superior to a host delaying DHCP process by xxx ms should be explain= ed > further. >=20 > (3) How "IPv6-only preferred" mode is supposed to be set at the host side= : >=20 > =3D=3D > A DHCP client SHOULD allow a device administrator to configure > IPv6-only preferred mode either for a specific interface (to indicate > that the device is IPv6-only capable if connected to a NAT64 network > via that interface) or for all interfaces. > =3D=3D >=20 > * I guess the default value when the option is supported by a host is to > disable including it in the request. The document should include a > discussion on the default behavior. > * If an explicit action is needed from the user to enable including the > option, having a discussion to what extent the feature is likely to be > enabled would be needed. >=20 > (4) The document is still mixing the DHCP client vs. host behaviors. For > example, >=20 > Clients not capable of operating in an IPv6-only NAT64 environment > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > MUST NOT include the IPv6-only Preferred option in the Parameter > Request List of any DHCP packets and MUST ignore that option in > packets received from DHCP servers. >=20 > does not make sense for a DHCP client. >=20 > Also, how the host is able to assess/determine that it is (not) capable t= o > behave in the IPv6 mode? >=20 > (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RFC85= 85 > says the following: >=20 > "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition > technologies for delivering IPv4 in IPv6-only connectivity. >=20 > While yours is: >=20 > IPv4-as-a-Service: a deployment scenario when end hosts are expected > to operate in IPv6-only mode by default and IPv4 addresses can be > assigned to some hosts if those hosts explicitly opt-in to receiving > IPv4 addresses. >=20 > (6) Do you consider a host with CLAT function as an IPv6-only host? >=20 > If so, the following definition should be updated to refer to "IPv4 > connectivity" rather than "IPv4" in general. This is because an IPv4 > address is required for CLAT for example. >=20 > =3D=3D > IPv6-only capable host: a host which does not require IPv4 and can > operate on IPv6-only networks. > =3D=3D >=20 > (7) Wouldn't the following add an extra delay for applications requiring > CLAT? >=20 > =3D=3D > The host MAY disable IPv4 stack > completely for V6ONLY_WAIT seconds or until the network disconnection > event happens. > =3D=3D >=20 > (8) Consider returning an address from the range defined in RFC7335 for > IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-on= ly > hosts (those with a CLAT for example). >=20 > =3D=3D=3D=3D > The result is that 192.0.0.0/29 may be used in any system > that requires IPv4 addresses for backward compatibility with IPv4 > communications in an IPv6-only network but does not emit IPv4 packets > "on the wire". > =3D=3D=3D=3D >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: dhcwg [mailto:dhcwg-bounces@ietf.org] De la part de Jen Linkova > > Envoy=E9=A0: mardi 10 d=E9cembre 2019 01:02 =C0=A0: dhcwg@ietf.org Cc= =A0: V6 Ops > > List Objet=A0: [dhcwg] Fwd: New Version Notification for > > draft-link-dhc-v6only- 01.txt > > > > Hello, > > > > Thanks to everyone for very productive centi-thread on > > draft-link-dhc-v6only-00 ;) > > Here is the improved version, -01. > > > > The main changes: > > > > - The option is not zero length anymore. It has 4-bytes value which > > might contain V6ONLY_WAIT timer. Benefits: > > --- allows the network administrators to pilot the changes and > > rollback quickly if needed; > > --- addressed some concern about an option having zero length > > (allegedly it might confuse some clients) > > > > - Using a dedicated address to return to clients is now an optional > > optimisation. By default the server is expected just to return a > > random address (as usual). > > > > - Typos fixed (probably some new typos added though). > > > > The authors would like the DHC WG to consider adopting this document. > > > > Thank you! > > > > ---------- Forwarded message --------- > > From: > > Date: Tue, Dec 10, 2019 at 10:44 AM > > Subject: New Version Notification for draft-link-dhc-v6only-01.txt > > To: Tomek Mrugalski , Lorenzo Colitti > > , Jen Linkova , Michael C. > > Richardson > > > > > > > > A new version of I-D, draft-link-dhc-v6only-01.txt has been > > successfully submitted by Jen Linkova and posted to the IETF > > repository. > > > > Name: draft-link-dhc-v6only > > Revision: 01 > > Title: IPv6-Only-Preferred Option for DHCP > > Document date: 2019-12-09 > > Group: Individual Submission > > Pages: 10 > > URL: > > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt > > Status: https://datatracker.ietf.org/doc/draft-link-dhc-v6only/ > > Htmlized: https://tools.ietf.org/html/draft-link-dhc-v6only-01 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-link-dhc- > v6only > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-link-dhc-v6on= ly- > 01 > > > > Abstract: > > This document specifies a DHCP option to indicate that a host > > supports an IPv6-only mode and willing to forgo obtaining an IPv4 > > address if the network provides IPv6 connectivity. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Dec 11 03:20:15 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F212003E; Wed, 11 Dec 2019 03:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=ALSGDC0q; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RRh3M8h1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLbOB93UIqsA; Wed, 11 Dec 2019 03:20:11 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530EC1200E9; Wed, 11 Dec 2019 03:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13426; q=dns/txt; s=iport; t=1576063211; x=1577272811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w84SjOddIADVNbz4N0d0lnG98L5gTmBTZaqqDk5ijhE=; b=ALSGDC0qDSdhYaKVam6G57mmMrDDlA4WcGZzKwrd9msIlqukcr+dLfOj Sd+/1Y3G+2d1W2d73j9fqMs7XaT9YHhz8pMG+zqvtTl0r7v6CeZsWGQTd DvaqmRgnv/DJlJVPP094ioaw/w5EZjJP1MF7kWR99mCRMkcaHphF9wo7f w=; IronPort-PHdr: =?us-ascii?q?9a23=3A0fMEmReEjVRLmzoam3+Fv0wllGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeDtaz4SF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AAAa0PBd/4QNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUspJwVsWCAECyoKg3mDRgOLB4JfiVuOK4J?= =?us-ascii?q?SA1QJAQEBDAEBGAsKAgEBhEACF4FuJDgTAgMNAQEEAQEBAgEFBG2FNwELhV4?= =?us-ascii?q?BAQEBAgEBARAREQwBASwJAgEEBwQCAQgRAwEBAQECAiMDAgICHwYLFAEICAI?= =?us-ascii?q?EDgUbB4I1SwGCRgMOIAECDKFYAoE4iGF1gTKCfgEBBYE5Ag5BgxcNC4IXCYE?= =?us-ascii?q?OKIUchnwaggCBEScggkw+ghtJAQECAQEYgTEWgxAygiyNPQcogkGFeJdYL0M?= =?us-ascii?q?Kgi+HJIovhCMbgkJ0hwKQCI5KiEmCF4txg2cCBAIEBQIOAQEFgWkiN4EhcBU?= =?us-ascii?q?aISoBgkEJRxEUjGYHAhqDUIUUhT90AYEnjG0BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,301,1571702400"; d="scan'208";a="388153087" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2019 11:20:09 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xBBBK9P2009223 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2019 11:20:09 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 05:20:08 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 06:20:07 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 11 Dec 2019 06:20:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtF6lQOWbUCZ/3lqOi/GNSxg8SsPpF8V8rtOr6Lw5oF2D8hCK7Z4JfX6HU8hOSW1T0hbZum9vHxicGt0yuV/61f/hVhOWkrzh660ojJAulaXe/L2nqYhFqEa3ktZXRFVL7cHx69BdIRw7zsTWLt8kgGg4c2UOY7FLnlXii4z1Zb83s/SVm2gCqbqy14Z5w9R6y6vZ4PrsEOJJo/DBh0evvLXAyjR4Ni+iENIrbIitffq/8l3Yd3lUftHtbOM2fjcAXYgOZ3Kp/K+28thUeBiDftaoXHHa0wwxMmigckryxe3BEC8DyuB1P7bMYiEFRefFcLNwIoDEy6pRDacoNCuMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w84SjOddIADVNbz4N0d0lnG98L5gTmBTZaqqDk5ijhE=; b=PLCZ/3+X5KGR+gkqoljFCFB9Hgwj6xNoBDtKZtjRjwT+ehLh0/yvok0DQvVTraRd/G7Ej6eL/k8215vwog1K/CMBnAQjK9q7Wy3mDArfULyYB++uNBQnMJLacsmWOqJXsDl92ucErQfXOvg5y1544iswFPayFi+iBlf+LDzf5o2xVdu2T23FgyY9Ae0AzpD3cYCtSV55r475yiBOpJcy90AFNsYUR8JY5+JBySbY8hvU6jJcj/E8KpN1Lw1kSA7POwvVAaOApv3tOou3I0Sob08eIBMiRQr2UtvIn76nSv6e1i6XasXs8qrv1wQjmQyYwH2KXUE54Jv+4Jz9agX9QQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w84SjOddIADVNbz4N0d0lnG98L5gTmBTZaqqDk5ijhE=; b=RRh3M8h1RoGOoVfsBTmMSAP0/4mLGGjOZbK/6gzLDSIjFhpEATgSOSKWbdmyrIDijhFlcYVElv0Q4igZmEqSNXKPTl5WyoIo+VdpAaODRG9mDCbwvy+6eQ2L7I7s+GR8J591ox7B4d4+nQsqvqgUbScFgwr+hsEHE3I6e1IBtWs= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB3338.namprd11.prod.outlook.com (20.176.122.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Wed, 11 Dec 2019 11:20:06 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2538.016; Wed, 11 Dec 2019 11:20:06 +0000 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" CC: Jen Linkova , "dhcwg@ietf.org" , "V6 Ops List" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKe0c/9wgABW+RQ= Date: Wed, 11 Dec 2019 11:20:06 +0000 Message-ID: <1BDB5CA6-4A86-47D7-9D12-F7D427E3F76A@cisco.com> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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=volz@cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 480f6839-cd61-4322-393c-08d77e2c1351 x-ms-traffictypediagnostic: DM6PR11MB3338: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(346002)(376002)(366004)(199004)(189003)(54164003)(13464003)(64756008)(66446008)(66556008)(71200400001)(76116006)(8676002)(91956017)(81156014)(81166006)(86362001)(66946007)(66476007)(15650500001)(54906003)(316002)(33656002)(6486002)(8936002)(186003)(6512007)(26005)(53546011)(6916009)(6506007)(2906002)(36756003)(66574012)(966005)(478600001)(5660300002)(2616005)(4326008)(19627235002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3338; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: INGDeGlrRinYgYZ7wayU8By/j7Al49F3APoKK/NFWyOWfL+LeRCUqGlibU3HTrOdPslCMDarSMTzcVEzLDo919JTWP8CVeATC5lluAx1p6QEAzQmME8PkUobIPbCcM7nyc2gQacknytZjDD6oESz07GCZswxQXdHePrXIzrGnjQJOtSg2+Mc9/Qre8zjuDs2RVRrHZvWWf6ncreJrrBF95rFIZSzZGQ4d383FU7wre0gqF8Az5hVMpKYY6q1kQ9ZsfEeHK7DRaBfUq8bFN3R801qtvXvBZyQs5Zga1zUV2f+NmZA47grtnd27qzUyJgK4hKkD2BbL3ue1FXWXCffb9eJwYSRtQQV+TWLwoHFdMZPk1aPR9oPu+VRNtjmiCL5z9b4NZASFpU6RPzZsf6gp0i5XSPcBEd+VcVsE5T3+dpkWmuBHzArLwiMu/Q0PbFiinhrOLc2SunOzu692TvxlWsRXw8F3/KJSiAc0x9cJyjE4wk0prIOQRTLsI5+mTKNzMyrA8lvnel2z681pF5llJ1Sev61OjDhYvFbwMRsKqeOaKBJf3tAikiZmjFtiDCYh8L0iX8+GCYjBouFm1Gpqw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 480f6839-cd61-4322-393c-08d77e2c1351 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 11:20:06.3385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8AJo0obz4M3ASRh6681z/fcVJfIJEOfsE5251OM1yhZdBKbFbRiAgFO2KiWCbNpD X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3338 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 11:20:14 -0000 Tm90IHN1cmUgaG93IHRoaXMgaXMgc3VwcG9zZWQgdG8gd29yayB0b2RheSAoaXMgdGhpcyBkb2N1 bWVudGVkIHNvbWV3aGVyZSk/IElzIGRoY3Agc2VydmVyIGFscmVhZHkgYXNzaWduaW5nIGFkZHJl c3NlcyBpbiB0aGUgc3BlY2lhbCByYW5nZT8gSWYgc28sIHdoeSBub3QgY29udGludWUgdGhhdCBw cmFjdGljZSBhbmQgZG9u4oCZdCBob25vciB0aGUgaXB2Ni1vbmx5IG9wdGlvbiBvbiBzZXJ2ZXIu DQoNCi0gQmVybmllDQoNCj4gT24gRGVjIDExLCAyMDE5LCBhdCAxOjI4IEFNLCAibW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3Rl Og0KPiANCj4g77u/SGkgQmVybmllLCANCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLiANCj4gDQo+ IENoZWVycywNCj4gTWVkDQo+IA0KPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBE ZSA6IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFpbHRvOnZvbHpAY2lzY28uY29tXQ0KPj4gRW52b3nD qSA6IG1hcmRpIDEwIGTDqWNlbWJyZSAyMDE5IDE3OjExDQo+PiDDgCA6IEJPVUNBREFJUiBNb2hh bWVkIFRHSS9PTE47IEplbiBMaW5rb3ZhOyBkaGN3Z0BpZXRmLm9yZw0KPj4gQ2MgOiBWNiBPcHMg TGlzdA0KPj4gT2JqZXQgOiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbGluay1kaGMtDQo+PiB2Nm9ubHktMDEudHh0DQo+PiANCj4+IEhpOg0KPj4g DQo+PiBJcyAoOCk6DQo+PiANCj4+ICAgICg4KSBDb25zaWRlciByZXR1cm5pbmcgYW4gYWRkcmVz cyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGluIFJGQzczMzUNCj4+IGZvciBJUHY2LW9ubHkgaG9z dHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkIGFueXdheSBmb3Igc29tZSBJUHY2 LQ0KPj4gb25seSBob3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0KPj4gDQo+ PiAgICA9PT09DQo+PiAgICAgICBUaGUgcmVzdWx0IGlzIHRoYXQgMTkyLjAuMC4wLzI5IG1heSBi ZSB1c2VkIGluIGFueSBzeXN0ZW0NCj4+ICAgICAgIHRoYXQgcmVxdWlyZXMgSVB2NCBhZGRyZXNz ZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0DQo+PiAgICAgICBjb21tdW5p Y2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0DQo+ PiBwYWNrZXRzDQo+PiAgICAgICAib24gdGhlIHdpcmUiLg0KPj4gICAgPT09PQ0KPj4gDQo+PiBC dXQgUkZDNzMzNSBzYXlzIChpbiBzZWN0aW9uIDQpOg0KPj4gDQo+PiAgIElBTkEgaGFzIGRlZmlu ZWQgYSB3ZWxsLWtub3duIHJhbmdlLCAxOTIuMC4wLjAvMjksIGluIFtSRkM2MzMzXSwNCj4+ICAg d2hpY2ggaXMgZGVkaWNhdGVkIGZvciBEUy1MaXRlLiAgQXMgZGVmaW5lZCBpbiBbUkZDNjMzM10s IHRoaXMgc3VibmV0DQo+PiAgIGlzIG9ubHkgcHJlc2VudCBiZXR3ZWVuIHRoZSBCNCBhbmQgdGhl IEFkZHJlc3MgRmFtaWx5IFRyYW5zaXRpb24NCj4+ICAgUm91dGVyIChBRlRSKSBhbmQgbmV2ZXIg ZW1pdHMgcGFja2V0cyBmcm9tIHRoaXMgcHJlZml4ICJvbiB0aGUgd2lyZSIuDQo+PiA8LS0tDQo+ PiAgIDQ2NFhMQVQgaGFzIHRoZSBzYW1lIG5lZWQgZm9yIGEgbm9uLXJvdXRlZCBJUHY0IHByZWZp eCwgYW5kIHRoaXMgc2FtZQ0KPj4gICBuZWVkIG1heSBiZSBjb21tb24gZm9yIG90aGVyIHNpbWls YXIgc29sdXRpb25zLiAgSXQgaXMgbW9zdCBwcnVkZW50DQo+PiAgIGFuZCBlZmZlY3RpdmUgdG8g Z2VuZXJhbGl6ZSAxOTIuMC4wLjAvMjkgZm9yIHRoZSB1c2Ugb2Ygc3VwcG9ydGluZw0KPj4gICBJ UHY0IGludGVyZmFjZXMgaW4gSVB2NiB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcyByYXRoZXIgdGhh biByZXNlcnZpbmcNCj4+ICAgYSBwcmVmaXggZm9yIGV2ZXJ5IHBvc3NpYmxlIHNvbHV0aW9uLg0K Pj4gDQo+PiBTbywgdGhpcyBhZGRyZXNzIGlzIG9ubHkgdXNlZCAib24gdGhlIGhvc3QiIChub3Qg b24gdGhlIHdpcmUpLCBzbyB3aHkgd291bGQNCj4+IHRoZXJlIGJlIGFueSBuZWVkIGZvciB0aGUg REhDUCBzZXJ2ZXIgdG8gYXNzaWduIHRoaXMgYWRkcmVzcz8NCj4gDQo+IFtNZWRdIFRoaXMgaXMg dG8gZWFzZSByZW1vdGUgdHJvdWJsZXNob290aW5nIG9mIHRoZSBJUHY0YWFTIGNvbXBvbmVudCAo Q0xBVCwgQjQpIG9mIHRoZSBJUHY2LW9ubHkgaG9zdC4gQ29udHJvbGxpbmcgdGhlIElQdjQgYWRk cmVzcyBjb25maWd1cmVkIGxvY2FsbHkgYWxsb3dzIHRvIG1ha2UgdXNlIG9mIHRvb2xzIHN1Y2gg YXMgUFJPQkUgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzM1KSB0byByZW1vdGVs eSBhc3Nlc3MgdGhlIHN0YXR1cyBvZiB0aGUgSVB2NGFhUyBjb21wb25lbnQgdmlhIGFuIElQdjYg bmV0d29yay4NCj4gDQo+PiANCj4+IEFuZCBhcyB0aGUgSVB2Ni1vbmx5IG9wdGlvbiBtZWFucyB0 aGF0IHRoZSBob3N0IG5ldmVyIGNvbXBsZXRlcyB0aGUNCj4+IERIQ1BESVNDT1ZFUi9PRkZFUi9S RVFVRVNUL0FDSyAoc3RvcHMgYXQgT0ZGRVIpLCB0aGlzIHdvcmsgY291bGQgbm90IGJlDQo+PiB1 c2VkIHRvIGFzc2lnbiBhbnkgYWRkcmVzcy4NCj4+IA0KPj4gLSBCZXJuaWUNCj4+IA0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGRoY3dnIDxkaGN3Zy1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YNCj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+ IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDEwLCAyMDE5IDU6MzIgQU0NCj4+IFRvOiBKZW4gTGlu a292YSA8ZnVycnkxM0BnbWFpbC5jb20+OyBkaGN3Z0BpZXRmLm9yZw0KPj4gQ2M6IFY2IE9wcyBM aXN0IDx2Nm9wc0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saW5rLWRoYy0NCj4+IHY2b25seS0wMS50eHQN Cj4+IA0KPj4gSGkgSmVuLA0KPj4gDQo+PiBUaGFuayB5b3UgZm9yIHNoYXJpbmcgdGhpcyB1cGRh dGVkIHZlcnNpb24uIEJlbG93IHNvbWUgcG9pbnRzIHRoYXQgSSBkbw0KPj4gdGhpbmsgbmVlZCBt b3JlIGNsYXJpZmljYXRpb24gaW4gdGhlIEktRDoNCj4+IA0KPj4gKDEpIFRoZSBkb2N1bWVudCBp cyB0b28gTkFUNjQgY2VudHJpYy4gVGhlIHByb3Bvc2FsIG1heSBhcHBseSBhcyB3ZWxsIGZvcg0K Pj4gb3RoZXIgSVB2Ni1vbmx5IGRlcGxveW1lbnQgc2NlbmFyaW9zICh0eXBpY2FsbHksIHVubWFu YWdlZCBJUHY2LW9ubHkgQ1BFcw0KPj4gd2l0aCBJUHY0YWFTKS4NCj4+IA0KPj4gKDIpIEEgZGlz Y3Vzc2lvbiBvbiB0aGUgYmVuZWZpdCBvZiB0aGlzIGV4dHJhIHNpZ25hbCBjb21wYXJlZCB0byBy ZWx5aW5nIG9uDQo+PiBleGlzdGluZyBzaWduYWxzIChwcmVmNjQsIGFmdHJfbmFtZSwgbWFwX2Nv bnRhaW5lci4uLikuIEZvciBleGFtcGxlLCBhIGhvc3QNCj4+IHRoYXQgc3VwcG9ydHMgdGhlIG9w dGlvbiBpcyByZWFkeSB0byB3YWl0IGF0IG1pbmltdW0gMzAwcyBhbmQgZGlzYWJsZSBpdHMNCj4+ IElQdjQgY29uZmlndXJhdGlvbiByZWdhcmRsZXNzIG9mIHdoYXQgaXMgaGFwcGVuaW5nIG9uIHRo ZSBJUHY2IGxlZy4gSG93IGlzDQo+PiB0aGF0IHN1cGVyaW9yIHRvIGEgaG9zdCBkZWxheWluZyBE SENQIHByb2Nlc3MgYnkgeHh4IG1zIHNob3VsZCBiZSBleHBsYWluZWQNCj4+IGZ1cnRoZXIuDQo+ PiANCj4+ICgzKSBIb3cgIklQdjYtb25seSBwcmVmZXJyZWQiIG1vZGUgaXMgc3VwcG9zZWQgdG8g YmUgc2V0IGF0IHRoZSBob3N0IHNpZGU6DQo+PiANCj4+ID09DQo+PiAgIEEgREhDUCBjbGllbnQg U0hPVUxEIGFsbG93IGEgZGV2aWNlIGFkbWluaXN0cmF0b3IgdG8gY29uZmlndXJlDQo+PiAgIElQ djYtb25seSBwcmVmZXJyZWQgbW9kZSBlaXRoZXIgZm9yIGEgc3BlY2lmaWMgaW50ZXJmYWNlICh0 byBpbmRpY2F0ZQ0KPj4gICB0aGF0IHRoZSBkZXZpY2UgaXMgSVB2Ni1vbmx5IGNhcGFibGUgaWYg Y29ubmVjdGVkIHRvIGEgTkFUNjQgbmV0d29yaw0KPj4gICB2aWEgdGhhdCBpbnRlcmZhY2UpIG9y IGZvciBhbGwgaW50ZXJmYWNlcy4NCj4+ID09DQo+PiANCj4+ICogSSBndWVzcyB0aGUgZGVmYXVs dCB2YWx1ZSB3aGVuIHRoZSBvcHRpb24gaXMgc3VwcG9ydGVkIGJ5IGEgaG9zdCBpcyB0bw0KPj4g ZGlzYWJsZSBpbmNsdWRpbmcgaXQgaW4gdGhlIHJlcXVlc3QuIFRoZSBkb2N1bWVudCBzaG91bGQg aW5jbHVkZSBhDQo+PiBkaXNjdXNzaW9uIG9uIHRoZSBkZWZhdWx0IGJlaGF2aW9yLg0KPj4gKiBJ ZiBhbiBleHBsaWNpdCBhY3Rpb24gaXMgbmVlZGVkIGZyb20gdGhlIHVzZXIgdG8gZW5hYmxlIGlu Y2x1ZGluZyB0aGUNCj4+IG9wdGlvbiwgaGF2aW5nIGEgZGlzY3Vzc2lvbiB0byB3aGF0IGV4dGVu dCB0aGUgZmVhdHVyZSBpcyBsaWtlbHkgdG8gYmUNCj4+IGVuYWJsZWQgd291bGQgYmUgbmVlZGVk Lg0KPj4gDQo+PiAoNCkgVGhlIGRvY3VtZW50IGlzIHN0aWxsIG1peGluZyB0aGUgREhDUCBjbGll bnQgdnMuIGhvc3QgYmVoYXZpb3JzLiBGb3INCj4+IGV4YW1wbGUsDQo+PiANCj4+ICAgQ2xpZW50 cyBub3QgY2FwYWJsZSBvZiBvcGVyYXRpbmcgaW4gYW4gSVB2Ni1vbmx5IE5BVDY0IGVudmlyb25t ZW50DQo+PiAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xg0KPj4gICBNVVNUIE5PVCBpbmNsdWRlIHRoZSBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiBp biB0aGUgUGFyYW1ldGVyDQo+PiAgIFJlcXVlc3QgTGlzdCBvZiBhbnkgREhDUCBwYWNrZXRzIGFu ZCBNVVNUIGlnbm9yZSB0aGF0IG9wdGlvbiBpbg0KPj4gICBwYWNrZXRzIHJlY2VpdmVkIGZyb20g REhDUCBzZXJ2ZXJzLg0KPj4gDQo+PiBkb2VzIG5vdCBtYWtlIHNlbnNlIGZvciBhIERIQ1AgY2xp ZW50Lg0KPj4gDQo+PiBBbHNvLCBob3cgdGhlIGhvc3QgaXMgYWJsZSB0byBhc3Nlc3MvZGV0ZXJt aW5lIHRoYXQgaXQgaXMgKG5vdCkgY2FwYWJsZSB0bw0KPj4gYmVoYXZlIGluIHRoZSBJUHY2IG1v ZGU/DQo+PiANCj4+ICg1KSBUaGUgZGVmaW5pdGlvbiBvZiBJUHY0YWFTIGlzIG5vdCBhbGlnbmVk IHdpdGggb3RoZXIgUkZDczogZS5nLiwgUkZDODU4NQ0KPj4gc2F5cyB0aGUgZm9sbG93aW5nOg0K Pj4gDQo+PiAgICJJUHY0YWFTIiBzdGFuZHMgZm9yICJJUHY0LWFzLWEtU2VydmljZSIsIG1lYW5p bmcgdHJhbnNpdGlvbg0KPj4gICB0ZWNobm9sb2dpZXMgZm9yIGRlbGl2ZXJpbmcgSVB2NCBpbiBJ UHY2LW9ubHkgY29ubmVjdGl2aXR5Lg0KPj4gDQo+PiBXaGlsZSB5b3VycyBpczoNCj4+IA0KPj4g ICBJUHY0LWFzLWEtU2VydmljZTogYSBkZXBsb3ltZW50IHNjZW5hcmlvIHdoZW4gZW5kIGhvc3Rz IGFyZSBleHBlY3RlZA0KPj4gICB0byBvcGVyYXRlIGluIElQdjYtb25seSBtb2RlIGJ5IGRlZmF1 bHQgYW5kIElQdjQgYWRkcmVzc2VzIGNhbiBiZQ0KPj4gICBhc3NpZ25lZCB0byBzb21lIGhvc3Rz IGlmIHRob3NlIGhvc3RzIGV4cGxpY2l0bHkgb3B0LWluIHRvIHJlY2VpdmluZw0KPj4gICBJUHY0 IGFkZHJlc3Nlcy4NCj4+IA0KPj4gKDYpIERvIHlvdSBjb25zaWRlciBhIGhvc3Qgd2l0aCBDTEFU IGZ1bmN0aW9uIGFzIGFuIElQdjYtb25seSBob3N0Pw0KPj4gDQo+PiBJZiBzbywgdGhlIGZvbGxv d2luZyBkZWZpbml0aW9uIHNob3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyIHRvICJJUHY0DQo+PiBj b25uZWN0aXZpdHkiIHJhdGhlciB0aGFuICJJUHY0IiBpbiBnZW5lcmFsLiBUaGlzIGlzIGJlY2F1 c2UgYW4gSVB2NA0KPj4gYWRkcmVzcyBpcyByZXF1aXJlZCBmb3IgQ0xBVCBmb3IgZXhhbXBsZS4N Cj4+IA0KPj4gPT0NCj4+ICAgSVB2Ni1vbmx5IGNhcGFibGUgaG9zdDogYSBob3N0IHdoaWNoIGRv ZXMgbm90IHJlcXVpcmUgSVB2NCBhbmQgY2FuDQo+PiAgIG9wZXJhdGUgb24gSVB2Ni1vbmx5IG5l dHdvcmtzLg0KPj4gPT0NCj4+IA0KPj4gKDcpIFdvdWxkbid0IHRoZSBmb2xsb3dpbmcgYWRkIGFu IGV4dHJhIGRlbGF5IGZvciBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nDQo+PiBDTEFUPw0KPj4gDQo+ PiA9PQ0KPj4gVGhlIGhvc3QgTUFZIGRpc2FibGUgSVB2NCBzdGFjaw0KPj4gICBjb21wbGV0ZWx5 IGZvciBWNk9OTFlfV0FJVCBzZWNvbmRzIG9yIHVudGlsIHRoZSBuZXR3b3JrIGRpc2Nvbm5lY3Rp b24NCj4+ICAgZXZlbnQgaGFwcGVucy4NCj4+ID09DQo+PiANCj4+ICg4KSBDb25zaWRlciByZXR1 cm5pbmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGluIFJGQzczMzUgZm9yDQo+ PiBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkIGFueXdh eSBmb3Igc29tZSBJUHY2LW9ubHkNCj4+IGhvc3RzICh0aG9zZSB3aXRoIGEgQ0xBVCBmb3IgZXhh bXBsZSkuDQo+PiANCj4+ID09PT0NCj4+ICAgVGhlIHJlc3VsdCBpcyB0aGF0IDE5Mi4wLjAuMC8y OSBtYXkgYmUgdXNlZCBpbiBhbnkgc3lzdGVtDQo+PiAgIHRoYXQgcmVxdWlyZXMgSVB2NCBhZGRy ZXNzZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0DQo+PiAgIGNvbW11bmlj YXRpb25zIGluIGFuIElQdjYtb25seSBuZXR3b3JrIGJ1dCBkb2VzIG5vdCBlbWl0IElQdjQgcGFj a2V0cw0KPj4gICAib24gdGhlIHdpcmUiLg0KPj4gPT09PQ0KPj4gDQo+PiBDaGVlcnMsDQo+PiBN ZWQNCj4+IA0KPj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+IERlIDogZGhjd2cg W21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEplbiBMaW5rb3Zh DQo+Pj4gRW52b3nDqSA6IG1hcmRpIDEwIGTDqWNlbWJyZSAyMDE5IDAxOjAyIMOAIDogZGhjd2dA aWV0Zi5vcmcgQ2MgOiBWNiBPcHMNCj4+PiBMaXN0IE9iamV0IDogW2RoY3dnXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+PiBkcmFmdC1saW5rLWRoYy12Nm9ubHktIDAxLnR4 dA0KPj4+IA0KPj4+IEhlbGxvLA0KPj4+IA0KPj4+IFRoYW5rcyB0byBldmVyeW9uZSBmb3IgdmVy eSBwcm9kdWN0aXZlIGNlbnRpLXRocmVhZCBvbg0KPj4+IGRyYWZ0LWxpbmstZGhjLXY2b25seS0w MCA7KQ0KPj4+IEhlcmUgaXMgdGhlIGltcHJvdmVkIHZlcnNpb24sIC0wMS4NCj4+PiANCj4+PiBU aGUgbWFpbiBjaGFuZ2VzOg0KPj4+IA0KPj4+IC0gVGhlIG9wdGlvbiBpcyBub3QgemVybyBsZW5n dGggYW55bW9yZS4gSXQgaGFzIDQtYnl0ZXMgdmFsdWUgd2hpY2gNCj4+PiBtaWdodCBjb250YWlu IFY2T05MWV9XQUlUIHRpbWVyLiBCZW5lZml0czoNCj4+PiAgICAtLS0gYWxsb3dzIHRoZSBuZXR3 b3JrIGFkbWluaXN0cmF0b3JzIHRvIHBpbG90IHRoZSBjaGFuZ2VzIGFuZA0KPj4+IHJvbGxiYWNr IHF1aWNrbHkgaWYgbmVlZGVkOw0KPj4+ICAgIC0tLSBhZGRyZXNzZWQgc29tZSBjb25jZXJuIGFi b3V0IGFuIG9wdGlvbiBoYXZpbmcgemVybyBsZW5ndGgNCj4+PiAoYWxsZWdlZGx5IGl0IG1pZ2h0 IGNvbmZ1c2Ugc29tZSBjbGllbnRzKQ0KPj4+IA0KPj4+IC0gVXNpbmcgYSBkZWRpY2F0ZWQgYWRk cmVzcyB0byByZXR1cm4gdG8gY2xpZW50cyBpcyBub3cgYW4gb3B0aW9uYWwNCj4+PiBvcHRpbWlz YXRpb24uIEJ5IGRlZmF1bHQgdGhlIHNlcnZlciBpcyBleHBlY3RlZCBqdXN0IHRvIHJldHVybiBh DQo+Pj4gcmFuZG9tIGFkZHJlc3MgKGFzIHVzdWFsKS4NCj4+PiANCj4+PiAtIFR5cG9zIGZpeGVk IChwcm9iYWJseSBzb21lIG5ldyB0eXBvcyBhZGRlZCB0aG91Z2gpLg0KPj4+IA0KPj4+IFRoZSBh dXRob3JzIHdvdWxkIGxpa2UgdGhlIERIQyBXRyB0byBjb25zaWRlciBhZG9wdGluZyB0aGlzIGRv Y3VtZW50Lg0KPj4+IA0KPj4+IFRoYW5rIHlvdSENCj4+PiANCj4+PiAtLS0tLS0tLS0tIEZvcndh cmRlZCBtZXNzYWdlIC0tLS0tLS0tLQ0KPj4+IEZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+DQo+Pj4gRGF0ZTogVHVlLCBEZWMgMTAsIDIwMTkgYXQgMTA6NDQgQU0NCj4+PiBTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50 eHQNCj4+PiBUbzogVG9tZWsgTXJ1Z2Fsc2tpIDx0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbT4s IExvcmVuem8gQ29saXR0aQ0KPj4+IDxsb3JlbnpvQGdvb2dsZS5jb20+LCBKZW4gTGlua292YSA8 ZnVycnlAZ29vZ2xlLmNvbT4sIE1pY2hhZWwgQy4NCj4+PiBSaWNoYXJkc29uIDxtY3IraWV0ZkBz YW5kZWxtYW4uY2E+DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50eHQgaGFzIGJlZW4NCj4+PiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEplbiBMaW5rb3ZhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4+PiByZXBv c2l0b3J5Lg0KPj4+IA0KPj4+IE5hbWU6ICAgICAgICAgICBkcmFmdC1saW5rLWRoYy12Nm9ubHkN Cj4+PiBSZXZpc2lvbjogICAgICAgMDENCj4+PiBUaXRsZTogICAgICAgICAgSVB2Ni1Pbmx5LVBy ZWZlcnJlZCBPcHRpb24gZm9yIERIQ1ANCj4+PiBEb2N1bWVudCBkYXRlOiAgMjAxOS0xMi0wOQ0K Pj4+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+PiBQYWdlczogICAg ICAgICAgMTANCj4+PiBVUkw6DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50eHQNCj4+PiBTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluay1kaGMtdjZvbmx5Lw0KPj4+ IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGluay1k aGMtdjZvbmx5LTAxDQo+Pj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluay1kaGMtDQo+PiB2Nm9ubHkNCj4+PiBEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpbmstZGhjLXY2 b25seS0NCj4+IDAxDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyBhIERIQ1Agb3B0aW9uIHRvIGluZGljYXRlIHRoYXQgYSBob3N0DQo+Pj4gICBzdXBw b3J0cyBhbiBJUHY2LW9ubHkgbW9kZSBhbmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4g SVB2NA0KPj4+ICAgYWRkcmVzcyBpZiB0aGUgbmV0d29yayBwcm92aWRlcyBJUHY2IGNvbm5lY3Rp dml0eS4NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0K Pj4+IHRvb2xzLmlldGYub3JnLg0KPj4+IA0KPj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4g DQo+Pj4gDQo+Pj4gLS0NCj4+PiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo+Pj4gDQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBkaGN3 ZyBtYWlsaW5nIGxpc3QNCj4+PiBkaGN3Z0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRoY3dnIG1haWxpbmcgbGlzdA0KPj4gZGhj d2dAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj d2cNCg== From nobody Wed Dec 11 04:49:03 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E70F120856; Wed, 11 Dec 2019 04:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rgbK7liXka2; Wed, 11 Dec 2019 04:48:59 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 603C4120850; Wed, 11 Dec 2019 04:48:59 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 47XxZK6NW2z2yK7; Wed, 11 Dec 2019 13:48:57 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 47XxZK56kmz3wbX; Wed, 11 Dec 2019 13:48:57 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 11 Dec 2019 13:48:57 +0100 From: To: "Bernie Volz (volz)" CC: Jen Linkova , "dhcwg@ietf.org" , "V6 Ops List" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKe0c/9wgABW+RSAAAwR4A== Date: Wed, 11 Dec 2019 12:48:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E8E97@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1BDB5CA6-4A86-47D7-9D12-F7D427E3F76A@cisco.com> In-Reply-To: <1BDB5CA6-4A86-47D7-9D12-F7D427E3F76A@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 12:49:01 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2 b2x6QGNpc2NvLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxMSBkw6ljZW1icmUgMjAxOSAx MjoyMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IEplbiBMaW5r b3ZhOyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3QNCj4gT2JqZXTCoDogUmU6IFtkaGN3Z10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLQ0KPiB2Nm9u bHktMDEudHh0DQo+IA0KPiBOb3Qgc3VyZSBob3cgdGhpcyBpcyBzdXBwb3NlZCB0byB3b3JrIHRv ZGF5IChpcyB0aGlzIGRvY3VtZW50ZWQgc29tZXdoZXJlKT8NCj4gSXMgZGhjcCBzZXJ2ZXIgYWxy ZWFkeSBhc3NpZ25pbmcgYWRkcmVzc2VzIGluIHRoZSBzcGVjaWFsIHJhbmdlPw0KDQpbTWVkXSBE SENQIHNlcnZlcnMgYXJlIG5vdCB1c2VkIHRvZGF5IHRvIGFzc2lnbiB0aGVzZSBhZGRyZXNzZXMu IFRoZSBzZWxlY3Rpb24gb2YgdGhlIGFkZHJlc3MgaXMgbG9jYWwgdG8gdGhlIGhvc3QuIFRoZXJl IGlzIG5vIGFtYmlndWl0eSBmb3Igc29tZSBJUHY0YWFTIHRlY2huaXF1ZXMgKERTLUxpdGUgdXNl cyAxOTIuMC4wLjIpIGJ1dCBub3QgZm9yIENMQVQgKDE5Mi4wLjAuMC8yOSkuDQoNCiBJZiBzbywg d2h5DQo+IG5vdCBjb250aW51ZSB0aGF0IHByYWN0aWNlIGFuZCBkb27igJl0IGhvbm9yIHRoZSBp cHY2LW9ubHkgb3B0aW9uIG9uIHNlcnZlci4NCg0KW01lZF0gVGhhdCB3b3VsZG4ndCB3b3JrIGJl Y2F1c2UgbXkgcHJvcG9zYWwgaXMgZm9yIHRoZSBzZXJ2ZXIgdG8gcmV0dXJuIHRoZSAqKiBzYW1l ICoqIGFkZHJlc3MgdG8gYWxsIHJlcXVlc3RpbmcgaG9zdHMgd2l0aCBpcHY2LW9ubHkgZW5hYmxl ZC4gVGhhdCBhZGRyZXNzIHdpbGwgYmUgcGFzc2VkIHRvIG1vZHVsZXMgc3VjaCBhcyBDTEFULiBU aGlzIGJlaGF2aW9yIGlzIGFscmVhZHkgcmVxdWlyZWQgYnkgdGhpcyBkcmFmdDogDQoNCiAgIEFz IGFuIG9wdGlvbmFsIG9wdGltaXphdGlvbiBhbiBJUHY2LW1vc3RseSBwb29sIE1BWSBiZSBjb25m aWd1cmVkDQogICB3aXRoIGEgZGVkaWNhdGVkIElQdjQgYWRkcmVzcyB0byBiZSByZXR1cm5lZCB0 byBJUHY2LW9ubHkgY2FwYWJsZQ0KICAgY2xpZW50cy4gIEluIHRoYXQgY2FzZSB0aGUgc2VydmVy IFNIT1VMRCBzcGVjaWZ5IHRoYXQgYWRkcmVzcyBhcyB0aGUNCiAgIGNsaWVudCdzIG5ldHdvcmsg YWRkcmVzcyBhbmQgTVVTVCBOT1QgdmVyaWZ5IGl0cyB1bmlxdWVuZXNzLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCg0KVGhl IHZhbHVlIEkgc2VlIGluIHJldHVybmluZyBhbiBhZGRyZXNzIGZyb20gdGhpcyB3ZWxsLWtub3du IHJhbmdlIGlzIHRoYXQgdGhlIGhvc3QgZG9lcyBub3QgZXZlbiBuZWVkIHRvIHBhdXNlLCBpLmUu LCB0aGlzIHRleHQgd29uJ3QgYmUgcmVxdWlyZWQgYW55bW9yZSBpbiB0aGUgZHJhZnQ6IA0KDQo9 PQ0KSWYgdGhlDQogICBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiByZXR1cm5lZCBieSB0aGUg c2VydmVyIGNvbnRhaW5zIG5vbi16ZXJvDQogICB2YWx1ZSB0aGUgY2xpZW50IFNIT1VMRCBzZXQg dGhlIFY2T05MWV9XQUlUIHRpbWVyIHRvIHRoYXQgdmFsdWUuICBJZg0KICAgdGhlIHNlcnZlciBy ZXR1cm5zIHplcm8gdmFsdWUgdGhlIGNsaWVudCBNVVNUIHVzZSBpdHMgb3duDQogICBjb25maWd1 cmF0aW9uIGZvciBWNk9OTFlfV0FJVCB0aW1lci4gIFRoZSBjbGllbnQgU0hPVUxEIHN0b3AgdGhl IERIQ1ANCiAgIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyBmb3IgYXQgbGVhc3QgVjZPTkxZX1dBSVQg c2Vjb25kcyBvciB1bnRpbCBhDQogICBuZXR3b3JrIGF0dGFjaG1lbnQgZXZlbnQgaGFwcGVucy4g IFRoZSBob3N0IE1BWSBkaXNhYmxlIElQdjQgc3RhY2sNCiAgIGNvbXBsZXRlbHkgZm9yIFY2T05M WV9XQUlUIHNlY29uZHMgb3IgdW50aWwgdGhlIG5ldHdvcmsgZGlzY29ubmVjdGlvbg0KICAgZXZl bnQgaGFwcGVucy4NCj09DQoNClRoZSBob3N0IHdvbid0IGVtaXQgSVB2NCBwYWNrZXRzICJvbiB0 aGUgd2lyZSIgd2hlbiBhc3NpZ25lZCB3aXRoIHN1Y2ggYWRkcmVzcy4NCg0KPiANCj4gLSBCZXJu aWUNCj4gDQo+ID4gT24gRGVjIDExLCAyMDE5LCBhdCAxOjI4IEFNLCAibW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSINCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0K PiA+DQo+ID4g77u/SGkgQmVybmllLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4N Cj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+ID4+IERlIDogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21d DQo+ID4+IEVudm95w6kgOiBtYXJkaSAxMCBkw6ljZW1icmUgMjAxOSAxNzoxMQ0KPiA+PiDDgCA6 IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEplbiBMaW5rb3ZhOyBkaGN3Z0BpZXRmLm9yZw0K PiA+PiBDYyA6IFY2IE9wcyBMaXN0DQo+ID4+IE9iamV0IDogUkU6IFtkaGN3Z10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLQ0KPiA+PiB2Nm9ubHktMDEu dHh0DQo+ID4+DQo+ID4+IEhpOg0KPiA+Pg0KPiA+PiBJcyAoOCk6DQo+ID4+DQo+ID4+ICAgICg4 KSBDb25zaWRlciByZXR1cm5pbmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGlu IFJGQzczMzUNCj4gPj4gZm9yIElQdjYtb25seSBob3N0cy4gU3VjaCBJUHY0IGFkZHJlc3NlcyBh cmUgcmVxdWlyZWQgYW55d2F5IGZvciBzb21lDQo+IElQdjYtDQo+ID4+IG9ubHkgaG9zdHMgKHRo b3NlIHdpdGggYSBDTEFUIGZvciBleGFtcGxlKS4NCj4gPj4NCj4gPj4gICAgPT09PQ0KPiA+PiAg ICAgICBUaGUgcmVzdWx0IGlzIHRoYXQgMTkyLjAuMC4wLzI5IG1heSBiZSB1c2VkIGluIGFueSBz eXN0ZW0NCj4gPj4gICAgICAgdGhhdCByZXF1aXJlcyBJUHY0IGFkZHJlc3NlcyBmb3IgYmFja3dh cmQgY29tcGF0aWJpbGl0eSB3aXRoIElQdjQNCj4gPj4gICAgICAgY29tbXVuaWNhdGlvbnMgaW4g YW4gSVB2Ni1vbmx5IG5ldHdvcmsgYnV0IGRvZXMgbm90IGVtaXQgSVB2NA0KPiA+PiBwYWNrZXRz DQo+ID4+ICAgICAgICJvbiB0aGUgd2lyZSIuDQo+ID4+ICAgID09PT0NCj4gPj4NCj4gPj4gQnV0 IFJGQzczMzUgc2F5cyAoaW4gc2VjdGlvbiA0KToNCj4gPj4NCj4gPj4gICBJQU5BIGhhcyBkZWZp bmVkIGEgd2VsbC1rbm93biByYW5nZSwgMTkyLjAuMC4wLzI5LCBpbiBbUkZDNjMzM10sDQo+ID4+ ICAgd2hpY2ggaXMgZGVkaWNhdGVkIGZvciBEUy1MaXRlLiAgQXMgZGVmaW5lZCBpbiBbUkZDNjMz M10sIHRoaXMgc3VibmV0DQo+ID4+ICAgaXMgb25seSBwcmVzZW50IGJldHdlZW4gdGhlIEI0IGFu ZCB0aGUgQWRkcmVzcyBGYW1pbHkgVHJhbnNpdGlvbg0KPiA+PiAgIFJvdXRlciAoQUZUUikgYW5k IG5ldmVyIGVtaXRzIHBhY2tldHMgZnJvbSB0aGlzIHByZWZpeCAib24gdGhlIHdpcmUiLg0KPiA+ PiA8LS0tDQo+ID4+ICAgNDY0WExBVCBoYXMgdGhlIHNhbWUgbmVlZCBmb3IgYSBub24tcm91dGVk IElQdjQgcHJlZml4LCBhbmQgdGhpcyBzYW1lDQo+ID4+ICAgbmVlZCBtYXkgYmUgY29tbW9uIGZv ciBvdGhlciBzaW1pbGFyIHNvbHV0aW9ucy4gIEl0IGlzIG1vc3QgcHJ1ZGVudA0KPiA+PiAgIGFu ZCBlZmZlY3RpdmUgdG8gZ2VuZXJhbGl6ZSAxOTIuMC4wLjAvMjkgZm9yIHRoZSB1c2Ugb2Ygc3Vw cG9ydGluZw0KPiA+PiAgIElQdjQgaW50ZXJmYWNlcyBpbiBJUHY2IHRyYW5zaXRpb24gdGVjaG5v bG9naWVzIHJhdGhlciB0aGFuIHJlc2VydmluZw0KPiA+PiAgIGEgcHJlZml4IGZvciBldmVyeSBw b3NzaWJsZSBzb2x1dGlvbi4NCj4gPj4NCj4gPj4gU28sIHRoaXMgYWRkcmVzcyBpcyBvbmx5IHVz ZWQgIm9uIHRoZSBob3N0IiAobm90IG9uIHRoZSB3aXJlKSwgc28gd2h5DQo+IHdvdWxkDQo+ID4+ IHRoZXJlIGJlIGFueSBuZWVkIGZvciB0aGUgREhDUCBzZXJ2ZXIgdG8gYXNzaWduIHRoaXMgYWRk cmVzcz8NCj4gPg0KPiA+IFtNZWRdIFRoaXMgaXMgdG8gZWFzZSByZW1vdGUgdHJvdWJsZXNob290 aW5nIG9mIHRoZSBJUHY0YWFTIGNvbXBvbmVudA0KPiAoQ0xBVCwgQjQpIG9mIHRoZSBJUHY2LW9u bHkgaG9zdC4gQ29udHJvbGxpbmcgdGhlIElQdjQgYWRkcmVzcyBjb25maWd1cmVkDQo+IGxvY2Fs bHkgYWxsb3dzIHRvIG1ha2UgdXNlIG9mIHRvb2xzIHN1Y2ggYXMgUFJPQkUNCj4gKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzM1KSB0byByZW1vdGVseSBhc3Nlc3MgdGhlIHN0YXR1 cyBvZiB0aGUNCj4gSVB2NGFhUyBjb21wb25lbnQgdmlhIGFuIElQdjYgbmV0d29yay4NCj4gPg0K PiA+Pg0KPiA+PiBBbmQgYXMgdGhlIElQdjYtb25seSBvcHRpb24gbWVhbnMgdGhhdCB0aGUgaG9z dCBuZXZlciBjb21wbGV0ZXMgdGhlDQo+ID4+IERIQ1BESVNDT1ZFUi9PRkZFUi9SRVFVRVNUL0FD SyAoc3RvcHMgYXQgT0ZGRVIpLCB0aGlzIHdvcmsgY291bGQgbm90IGJlDQo+ID4+IHVzZWQgdG8g YXNzaWduIGFueSBhZGRyZXNzLg0KPiA+Pg0KPiA+PiAtIEJlcm5pZQ0KPiA+Pg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBkaGN3ZyA8ZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+ID4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20N Cj4gPj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTAsIDIwMTkgNTozMiBBTQ0KPiA+PiBUbzog SmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsgZGhjd2dAaWV0Zi5vcmcNCj4gPj4gQ2M6 IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFtkaGN3Z10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLQ0KPiA+PiB2 Nm9ubHktMDEudHh0DQo+ID4+DQo+ID4+IEhpIEplbiwNCj4gPj4NCj4gPj4gVGhhbmsgeW91IGZv ciBzaGFyaW5nIHRoaXMgdXBkYXRlZCB2ZXJzaW9uLiBCZWxvdyBzb21lIHBvaW50cyB0aGF0IEkg ZG8NCj4gPj4gdGhpbmsgbmVlZCBtb3JlIGNsYXJpZmljYXRpb24gaW4gdGhlIEktRDoNCj4gPj4N Cj4gPj4gKDEpIFRoZSBkb2N1bWVudCBpcyB0b28gTkFUNjQgY2VudHJpYy4gVGhlIHByb3Bvc2Fs IG1heSBhcHBseSBhcyB3ZWxsDQo+IGZvcg0KPiA+PiBvdGhlciBJUHY2LW9ubHkgZGVwbG95bWVu dCBzY2VuYXJpb3MgKHR5cGljYWxseSwgdW5tYW5hZ2VkIElQdjYtb25seQ0KPiBDUEVzDQo+ID4+ IHdpdGggSVB2NGFhUykuDQo+ID4+DQo+ID4+ICgyKSBBIGRpc2N1c3Npb24gb24gdGhlIGJlbmVm aXQgb2YgdGhpcyBleHRyYSBzaWduYWwgY29tcGFyZWQgdG8gcmVseWluZw0KPiBvbg0KPiA+PiBl eGlzdGluZyBzaWduYWxzIChwcmVmNjQsIGFmdHJfbmFtZSwgbWFwX2NvbnRhaW5lci4uLikuIEZv ciBleGFtcGxlLCBhDQo+IGhvc3QNCj4gPj4gdGhhdCBzdXBwb3J0cyB0aGUgb3B0aW9uIGlzIHJl YWR5IHRvIHdhaXQgYXQgbWluaW11bSAzMDBzIGFuZCBkaXNhYmxlDQo+IGl0cw0KPiA+PiBJUHY0 IGNvbmZpZ3VyYXRpb24gcmVnYXJkbGVzcyBvZiB3aGF0IGlzIGhhcHBlbmluZyBvbiB0aGUgSVB2 NiBsZWcuIEhvdw0KPiBpcw0KPiA+PiB0aGF0IHN1cGVyaW9yIHRvIGEgaG9zdCBkZWxheWluZyBE SENQIHByb2Nlc3MgYnkgeHh4IG1zIHNob3VsZCBiZQ0KPiBleHBsYWluZWQNCj4gPj4gZnVydGhl ci4NCj4gPj4NCj4gPj4gKDMpIEhvdyAiSVB2Ni1vbmx5IHByZWZlcnJlZCIgbW9kZSBpcyBzdXBw b3NlZCB0byBiZSBzZXQgYXQgdGhlIGhvc3QNCj4gc2lkZToNCj4gPj4NCj4gPj4gPT0NCj4gPj4g ICBBIERIQ1AgY2xpZW50IFNIT1VMRCBhbGxvdyBhIGRldmljZSBhZG1pbmlzdHJhdG9yIHRvIGNv bmZpZ3VyZQ0KPiA+PiAgIElQdjYtb25seSBwcmVmZXJyZWQgbW9kZSBlaXRoZXIgZm9yIGEgc3Bl Y2lmaWMgaW50ZXJmYWNlICh0byBpbmRpY2F0ZQ0KPiA+PiAgIHRoYXQgdGhlIGRldmljZSBpcyBJ UHY2LW9ubHkgY2FwYWJsZSBpZiBjb25uZWN0ZWQgdG8gYSBOQVQ2NCBuZXR3b3JrDQo+ID4+ICAg dmlhIHRoYXQgaW50ZXJmYWNlKSBvciBmb3IgYWxsIGludGVyZmFjZXMuDQo+ID4+ID09DQo+ID4+ DQo+ID4+ICogSSBndWVzcyB0aGUgZGVmYXVsdCB2YWx1ZSB3aGVuIHRoZSBvcHRpb24gaXMgc3Vw cG9ydGVkIGJ5IGEgaG9zdCBpcyB0bw0KPiA+PiBkaXNhYmxlIGluY2x1ZGluZyBpdCBpbiB0aGUg cmVxdWVzdC4gVGhlIGRvY3VtZW50IHNob3VsZCBpbmNsdWRlIGENCj4gPj4gZGlzY3Vzc2lvbiBv biB0aGUgZGVmYXVsdCBiZWhhdmlvci4NCj4gPj4gKiBJZiBhbiBleHBsaWNpdCBhY3Rpb24gaXMg bmVlZGVkIGZyb20gdGhlIHVzZXIgdG8gZW5hYmxlIGluY2x1ZGluZyB0aGUNCj4gPj4gb3B0aW9u LCBoYXZpbmcgYSBkaXNjdXNzaW9uIHRvIHdoYXQgZXh0ZW50IHRoZSBmZWF0dXJlIGlzIGxpa2Vs eSB0byBiZQ0KPiA+PiBlbmFibGVkIHdvdWxkIGJlIG5lZWRlZC4NCj4gPj4NCj4gPj4gKDQpIFRo ZSBkb2N1bWVudCBpcyBzdGlsbCBtaXhpbmcgdGhlIERIQ1AgY2xpZW50IHZzLiBob3N0IGJlaGF2 aW9ycy4gRm9yDQo+ID4+IGV4YW1wbGUsDQo+ID4+DQo+ID4+ICAgQ2xpZW50cyBub3QgY2FwYWJs ZSBvZiBvcGVyYXRpbmcgaW4gYW4gSVB2Ni1vbmx5IE5BVDY0IGVudmlyb25tZW50DQo+ID4+ICAg Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4+ICAg TVVTVCBOT1QgaW5jbHVkZSB0aGUgSVB2Ni1vbmx5IFByZWZlcnJlZCBvcHRpb24gaW4gdGhlIFBh cmFtZXRlcg0KPiA+PiAgIFJlcXVlc3QgTGlzdCBvZiBhbnkgREhDUCBwYWNrZXRzIGFuZCBNVVNU IGlnbm9yZSB0aGF0IG9wdGlvbiBpbg0KPiA+PiAgIHBhY2tldHMgcmVjZWl2ZWQgZnJvbSBESENQ IHNlcnZlcnMuDQo+ID4+DQo+ID4+IGRvZXMgbm90IG1ha2Ugc2Vuc2UgZm9yIGEgREhDUCBjbGll bnQuDQo+ID4+DQo+ID4+IEFsc28sIGhvdyB0aGUgaG9zdCBpcyBhYmxlIHRvIGFzc2Vzcy9kZXRl cm1pbmUgdGhhdCBpdCBpcyAobm90KSBjYXBhYmxlDQo+IHRvDQo+ID4+IGJlaGF2ZSBpbiB0aGUg SVB2NiBtb2RlPw0KPiA+Pg0KPiA+PiAoNSkgVGhlIGRlZmluaXRpb24gb2YgSVB2NGFhUyBpcyBu b3QgYWxpZ25lZCB3aXRoIG90aGVyIFJGQ3M6IGUuZy4sDQo+IFJGQzg1ODUNCj4gPj4gc2F5cyB0 aGUgZm9sbG93aW5nOg0KPiA+Pg0KPiA+PiAgICJJUHY0YWFTIiBzdGFuZHMgZm9yICJJUHY0LWFz LWEtU2VydmljZSIsIG1lYW5pbmcgdHJhbnNpdGlvbg0KPiA+PiAgIHRlY2hub2xvZ2llcyBmb3Ig ZGVsaXZlcmluZyBJUHY0IGluIElQdjYtb25seSBjb25uZWN0aXZpdHkuDQo+ID4+DQo+ID4+IFdo aWxlIHlvdXJzIGlzOg0KPiA+Pg0KPiA+PiAgIElQdjQtYXMtYS1TZXJ2aWNlOiBhIGRlcGxveW1l bnQgc2NlbmFyaW8gd2hlbiBlbmQgaG9zdHMgYXJlIGV4cGVjdGVkDQo+ID4+ICAgdG8gb3BlcmF0 ZSBpbiBJUHY2LW9ubHkgbW9kZSBieSBkZWZhdWx0IGFuZCBJUHY0IGFkZHJlc3NlcyBjYW4gYmUN Cj4gPj4gICBhc3NpZ25lZCB0byBzb21lIGhvc3RzIGlmIHRob3NlIGhvc3RzIGV4cGxpY2l0bHkg b3B0LWluIHRvIHJlY2VpdmluZw0KPiA+PiAgIElQdjQgYWRkcmVzc2VzLg0KPiA+Pg0KPiA+PiAo NikgRG8geW91IGNvbnNpZGVyIGEgaG9zdCB3aXRoIENMQVQgZnVuY3Rpb24gYXMgYW4gSVB2Ni1v bmx5IGhvc3Q/DQo+ID4+DQo+ID4+IElmIHNvLCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gc2hv dWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXIgdG8gIklQdjQNCj4gPj4gY29ubmVjdGl2aXR5IiByYXRo ZXIgdGhhbiAiSVB2NCIgaW4gZ2VuZXJhbC4gVGhpcyBpcyBiZWNhdXNlIGFuIElQdjQNCj4gPj4g YWRkcmVzcyBpcyByZXF1aXJlZCBmb3IgQ0xBVCBmb3IgZXhhbXBsZS4NCj4gPj4NCj4gPj4gPT0N Cj4gPj4gICBJUHY2LW9ubHkgY2FwYWJsZSBob3N0OiBhIGhvc3Qgd2hpY2ggZG9lcyBub3QgcmVx dWlyZSBJUHY0IGFuZCBjYW4NCj4gPj4gICBvcGVyYXRlIG9uIElQdjYtb25seSBuZXR3b3Jrcy4N Cj4gPj4gPT0NCj4gPj4NCj4gPj4gKDcpIFdvdWxkbid0IHRoZSBmb2xsb3dpbmcgYWRkIGFuIGV4 dHJhIGRlbGF5IGZvciBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nDQo+ID4+IENMQVQ/DQo+ID4+DQo+ ID4+ID09DQo+ID4+IFRoZSBob3N0IE1BWSBkaXNhYmxlIElQdjQgc3RhY2sNCj4gPj4gICBjb21w bGV0ZWx5IGZvciBWNk9OTFlfV0FJVCBzZWNvbmRzIG9yIHVudGlsIHRoZSBuZXR3b3JrIGRpc2Nv bm5lY3Rpb24NCj4gPj4gICBldmVudCBoYXBwZW5zLg0KPiA+PiA9PQ0KPiA+Pg0KPiA+PiAoOCkg Q29uc2lkZXIgcmV0dXJuaW5nIGFuIGFkZHJlc3MgZnJvbSB0aGUgcmFuZ2UgZGVmaW5lZCBpbiBS RkM3MzM1IGZvcg0KPiA+PiBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMgYXJl IHJlcXVpcmVkIGFueXdheSBmb3Igc29tZSBJUHY2LQ0KPiBvbmx5DQo+ID4+IGhvc3RzICh0aG9z ZSB3aXRoIGEgQ0xBVCBmb3IgZXhhbXBsZSkuDQo+ID4+DQo+ID4+ID09PT0NCj4gPj4gICBUaGUg cmVzdWx0IGlzIHRoYXQgMTkyLjAuMC4wLzI5IG1heSBiZSB1c2VkIGluIGFueSBzeXN0ZW0NCj4g Pj4gICB0aGF0IHJlcXVpcmVzIElQdjQgYWRkcmVzc2VzIGZvciBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggSVB2NA0KPiA+PiAgIGNvbW11bmljYXRpb25zIGluIGFuIElQdjYtb25seSBuZXR3 b3JrIGJ1dCBkb2VzIG5vdCBlbWl0IElQdjQgcGFja2V0cw0KPiA+PiAgICJvbiB0aGUgd2lyZSIu DQo+ID4+ID09PT0NCj4gPj4NCj4gPj4gQ2hlZXJzLA0KPiA+PiBNZWQNCj4gPj4NCj4gPj4+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+Pj4gRGUgOiBkaGN3ZyBbbWFpbHRvOmRoY3dn LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmVuIExpbmtvdmENCj4gPj4+IEVudm95 w6kgOiBtYXJkaSAxMCBkw6ljZW1icmUgMjAxOSAwMTowMiDDgCA6IGRoY3dnQGlldGYub3JnIENj IDogVjYgT3BzDQo+ID4+PiBMaXN0IE9iamV0IDogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj4gPj4+IGRyYWZ0LWxpbmstZGhjLXY2b25seS0gMDEudHh0DQo+ID4+ Pg0KPiA+Pj4gSGVsbG8sDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIHRvIGV2ZXJ5b25lIGZvciB2ZXJ5 IHByb2R1Y3RpdmUgY2VudGktdGhyZWFkIG9uDQo+ID4+PiBkcmFmdC1saW5rLWRoYy12Nm9ubHkt MDAgOykNCj4gPj4+IEhlcmUgaXMgdGhlIGltcHJvdmVkIHZlcnNpb24sIC0wMS4NCj4gPj4+DQo+ ID4+PiBUaGUgbWFpbiBjaGFuZ2VzOg0KPiA+Pj4NCj4gPj4+IC0gVGhlIG9wdGlvbiBpcyBub3Qg emVybyBsZW5ndGggYW55bW9yZS4gSXQgaGFzIDQtYnl0ZXMgdmFsdWUgd2hpY2gNCj4gPj4+IG1p Z2h0IGNvbnRhaW4gVjZPTkxZX1dBSVQgdGltZXIuIEJlbmVmaXRzOg0KPiA+Pj4gICAgLS0tIGFs bG93cyB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB0byBwaWxvdCB0aGUgY2hhbmdlcyBhbmQN Cj4gPj4+IHJvbGxiYWNrIHF1aWNrbHkgaWYgbmVlZGVkOw0KPiA+Pj4gICAgLS0tIGFkZHJlc3Nl ZCBzb21lIGNvbmNlcm4gYWJvdXQgYW4gb3B0aW9uIGhhdmluZyB6ZXJvIGxlbmd0aA0KPiA+Pj4g KGFsbGVnZWRseSBpdCBtaWdodCBjb25mdXNlIHNvbWUgY2xpZW50cykNCj4gPj4+DQo+ID4+PiAt IFVzaW5nIGEgZGVkaWNhdGVkIGFkZHJlc3MgdG8gcmV0dXJuIHRvIGNsaWVudHMgaXMgbm93IGFu IG9wdGlvbmFsDQo+ID4+PiBvcHRpbWlzYXRpb24uIEJ5IGRlZmF1bHQgdGhlIHNlcnZlciBpcyBl eHBlY3RlZCBqdXN0IHRvIHJldHVybiBhDQo+ID4+PiByYW5kb20gYWRkcmVzcyAoYXMgdXN1YWwp Lg0KPiA+Pj4NCj4gPj4+IC0gVHlwb3MgZml4ZWQgKHByb2JhYmx5IHNvbWUgbmV3IHR5cG9zIGFk ZGVkIHRob3VnaCkuDQo+ID4+Pg0KPiA+Pj4gVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0aGUgREhD IFdHIHRvIGNvbnNpZGVyIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuDQo+ID4+Pg0KPiA+Pj4gVGhh bmsgeW91IQ0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tDQo+ID4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+Pj4gRGF0ZTog VHVlLCBEZWMgMTAsIDIwMTkgYXQgMTA6NDQgQU0NCj4gPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPiA+Pj4gVG86 IFRvbWVrIE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+LCBMb3JlbnpvIENv bGl0dGkNCj4gPj4+IDxsb3JlbnpvQGdvb2dsZS5jb20+LCBKZW4gTGlua292YSA8ZnVycnlAZ29v Z2xlLmNvbT4sIE1pY2hhZWwgQy4NCj4gPj4+IFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1h bi5jYT4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0IGhhcyBiZWVuDQo+ID4+PiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEplbiBMaW5rb3ZhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gPj4+IHJl cG9zaXRvcnkuDQo+ID4+Pg0KPiA+Pj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhjLXY2 b25seQ0KPiA+Pj4gUmV2aXNpb246ICAgICAgIDAxDQo+ID4+PiBUaXRsZTogICAgICAgICAgSVB2 Ni1Pbmx5LVByZWZlcnJlZCBPcHRpb24gZm9yIERIQ1ANCj4gPj4+IERvY3VtZW50IGRhdGU6ICAy MDE5LTEyLTA5DQo+ID4+PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ ID4+PiBQYWdlczogICAgICAgICAgMTANCj4gPj4+IFVSTDoNCj4gPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0DQo+ID4+ PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bGluay1kaGMtdjZvbmx5Lw0KPiA+Pj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDENCj4gPj4+IEh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbmstZGhjLQ0K PiA+PiB2Nm9ubHkNCj4gPj4+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtbGluay1kaGMtDQo+IHY2b25seS0NCj4gPj4gMDENCj4gPj4+DQo+ ID4+PiBBYnN0cmFjdDoNCj4gPj4+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBESENQIG9w dGlvbiB0byBpbmRpY2F0ZSB0aGF0IGEgaG9zdA0KPiA+Pj4gICBzdXBwb3J0cyBhbiBJUHY2LW9u bHkgbW9kZSBhbmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4gSVB2NA0KPiA+Pj4gICBh ZGRyZXNzIGlmIHRoZSBuZXR3b3JrIHByb3ZpZGVzIElQdjYgY29ubmVjdGl2aXR5Lg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+PiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPj4+ IHRvb2xzLmlldGYub3JnLg0KPiA+Pj4NCj4gPj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo+ID4+ Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiA+Pj4gZGhjd2dAaWV0Zi5vcmcNCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gZGhjd2cg bWFpbGluZyBsaXN0DQo+ID4+IGRoY3dnQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From nobody Wed Dec 11 05:30:25 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4857D1201CE; Wed, 11 Dec 2019 05:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=CcNO46uL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cXP9BG0o Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWWZRBNW-Lyp; Wed, 11 Dec 2019 05:30:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575C412011C; Wed, 11 Dec 2019 05:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18602; q=dns/txt; s=iport; t=1576071012; x=1577280612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6ZV27hjkNu5S42QGwg3X120rW2VLiYoqjnoTSraoqpk=; b=CcNO46uLSFNeqCPvrrI+E4GReqTdDNSm35mW64ghBKmcP+B5vzvSbOuM +VSPPI+iiMQLUatXq0tc7zopBxz6mK/H2hhLkAO3/64vUxjBsEx3diUb8 Ow0fZuq1epGSzXsS7XoVH0scm+Z6Mr8W2buRFZNfGDLAy5PKhtVyfR9bf g=; IronPort-PHdr: =?us-ascii?q?9a23=3AjgV71RyMIEJQY9zXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRGN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A+GsHbIQKUh?= =?us-ascii?q?YEjcsMmAl1HsmBG2XwLeXhaGoxG8ERHFI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AADS7vBd/40NJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUspJwVsWCAECyoKg3mDRgOLCYJfgQGIWo4?= =?us-ascii?q?rglIDVAkBAQEMAQEYCwoCAQGEQAIXgW4kOBMCAw0BAQQBAQECAQUEbYU3AQu?= =?us-ascii?q?FXgEBAQEDAQEQEREMAQEsCQIBCwQCAQgRAwEBAQECAiMDAgICHwYLFAEICAI?= =?us-ascii?q?EDgUIEweCNUyCRgMuAQIMoWMCgTiIYXWBMoJ+AQEFgTkCDkGDEQ0LghcJgQ4?= =?us-ascii?q?ohRyGfBqCAIERR4IXNT6CG0kBAQIBARiBMRiDDjKCLI09ByiCQYV4l1gvQwq?= =?us-ascii?q?CL4ckii+EPoJCdIcCkAiOSohJgheLcYNnAgQCBAUCDgEBBYFpIjeBIXAVGiG?= =?us-ascii?q?CbAlHERSMZgcCGoNQhRSFP3QBgSeMbQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.69,301,1571702400"; d="scan'208";a="593781686" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2019 13:30:09 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xBBDU9IL030342 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2019 13:30:09 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 07:30:08 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Dec 2019 08:30:08 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 11 Dec 2019 08:30:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cyx72jyJifc1gjHETDvHsCFohQhwpjUVddoYjwPeuV7ctl/c/ah/znlCukhYhf1lwcAZde4OXM6DBWdmBYtiwrlO+tQ5CkENi2qmQSQbSW3+4x1RSmsKjWS2UbTsBzQ8IXGOkV5qQ6HKKV5gkuey3yniBvrEr8gqZxHBZ1YhzET7nOno+98Qfdl7+4VeJZ2KWwKDj0MoRLUFQE8drPsipEe6nc5U1YZoeV8LPo/sT56XWSvATwpRTuuY8JPPOiaqRDUhawaut+21y4eXMEIRG17fXZcjBIeZWO47e4HyddTxqC8MydovCz03rjZJ81cDgb6ty6XvQAuw9wN9Tpp7fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ZV27hjkNu5S42QGwg3X120rW2VLiYoqjnoTSraoqpk=; b=SQ9Aa33o3E4gjGiEZqopUdbvRO/enCZ6XpXqeletsyoKrgiTcQ+bwNX1Ash8N8l67MryrABA3n8KQyshDydzN6iLm+fm7NyI6pLHI9q0+rGHdr9wKGaCWJ8la0iMFz2oIqQgY4XDw/vqBNGDIPaH1iBT6LyeAbRYzK1YOjR/w0vfDomBt1JfvyIITsvANGr8raPa5jB3cG+sGlK4DHx460a6ogaMc/Q7jOTYUXDFPoFO8Rk5csarMIXNOkbOz8Lfq+n3NsTwkzcdbljtVMSjFKBmuPaS9ZQH8FUNsUD+PWEWd34QJqBStZRAc+I0KlLzBAIdIPvwO/NPz3qHcYSNCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ZV27hjkNu5S42QGwg3X120rW2VLiYoqjnoTSraoqpk=; b=cXP9BG0ognSw9g14CJfCzAXK3ceb89BhMiegcMneldhv64/rhBhJ5xyFWDOBH6zpBfDZMD0tRAT/ohkwp1W8HtPzZ3X3W/9JktbbQZ4/cffFhUSs9y1mXxXEDFk07WvGouKE5tKR/D/NVYUYkBFMXzx9U8ySJex1+4oIyR4MQqE= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB2716.namprd11.prod.outlook.com (20.176.99.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Wed, 11 Dec 2019 13:30:07 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::4194:dade:1d47:2678%6]) with mapi id 15.20.2538.016; Wed, 11 Dec 2019 13:30:07 +0000 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" CC: Jen Linkova , "dhcwg@ietf.org" , "V6 Ops List" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKe0c/9wgABW+RSAAAwR4IAAFzbA Date: Wed, 11 Dec 2019 13:30:06 +0000 Message-ID: References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1BDB5CA6-4A86-47D7-9D12-F7D427E3F76A@cisco.com> <787AE7BB302AE849A7480A190F8B9330313E8E97@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E8E97@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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=volz@cisco.com; x-originating-ip: [173.38.117.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0c7efad-e293-449f-2c8e-08d77e3e3ced x-ms-traffictypediagnostic: DM6PR11MB2716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(396003)(366004)(13464003)(189003)(54164003)(199004)(8936002)(19627235002)(71200400001)(66556008)(66946007)(9686003)(53546011)(6506007)(6916009)(76116006)(52536014)(64756008)(66446008)(66476007)(478600001)(81156014)(81166006)(8676002)(86362001)(2906002)(26005)(4326008)(15650500001)(55016002)(7696005)(33656002)(5660300002)(966005)(66574012)(54906003)(186003)(316002)(30864003)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2716; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jjg2w7dmR0IP0Tyi9Hi9XP4hny/IqQviWANndwm6PRIwr9DBDZj49I+D7X0RIEzg8Y57FISapmVak9Fs28Q2fKyJm07iYNA3CqHoiXwCJc/DQzUHthOSSFzuBZI1rSF7IVKX4McOU8Pp/dizv+zoeAmmzsAHlBDVYpZ7uRa0J+I0gocC1AfCdYM263yQXJlosk1OzRpkv7ISdTlbNc+uxA0mY1Tg5HGx7a4rzjSes4Y9A9PofXGGIKASifpi6kMU+V30qYcTuzjNDJ2S1WZjX2PxwBK8PdOX+I7mG7yJVvlKnZbieOt4pmmakdkeUWnVvXFmBqNLKCYRc4hnxLapPM6T95KkuWtAAVm5Sz0cIds1rxoojNPgYm6tVbzftWVe0fTfzFt3G/zQm5fTkQVK/7/zPszpovx1vD4Ps4O9HzTEty/W0aXnrtUIwDElneLSg1lXvI4OBoys7+20gvXoe7gFOhss1S3MhK/TYOdAY0d0eV90v05xKJVG5Z9BZ2D2R0TQJD0a7BLYhXGs+4ImxModG6Wkx67NBGc3BiTWP6lGMGUX7f/aKBioq0FuBAPyAMHrBtMRSlZoOMrjF7htoQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a0c7efad-e293-449f-2c8e-08d77e3e3ced X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 13:30:07.0853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /5dK9OsS8RfMsM8KjA1Vjh+FAmpztRgcWyS6JtQ1FSdLsS8N1ajb2ScI/fFI+E6T X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2716 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 13:30:17 -0000 TWVkOg0KDQpJZiB0aGlzIG9wdGlvbiBpcyBpbiBwbGF5LCBubyBhZGRyZXNzIGlzICJhc3NpZ25l ZCIgdG8gdGhlIGNsaWVudCBhcyB0aGF0IHJlcXVpcmVzIHRoZSBESENQUkVRVUVTVC9ESENQQUNL IG1lc3NhZ2VzIGFuZCB0aGUgY2xpZW50ICJzdG9wcyIgYWZ0ZXIgYSBESENQT0ZGRVIgaWYgdGhl IG9wdGlvbiB3YXMgcmV0dXJuZWQuIFNvLCB5b3UgY2FuJ3QgdXNlIHRoaXMgaWYgeW91IHdhbnQg dG8gYXNzaWduIGFuIGFkZHJlc3MuDQoNCkknbSBub3Qgc3VyZSB3aGF0IGlzIGJlaW5nIGRvbmUg dG9kYXk6DQoxKSBBcmUgeW91IHNheWluZyB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciB0aGlzIGlu IERIQ1AuIElmIHNvLCB0aGVuIHRoaXMgaXMgbm90IHNvbWV0aGluZyB0aGF0IGNhbiBiZSB1c2Vk IHRvIGFjdGl2YXRlIHRoaXMgc3VwcG9ydC4NCjIpIEFyZSB5b3Ugc2F5aW5nIHRoYXQgaXQgd29y a3MgZmluZSBhcyBpcyB0b2RheSAoc2luY2UgdGhlIERIQ1Agc2VydmVyIGNhbiBiZSBjb25maWd1 cmVkIChzb21laG93KSB0byByZXR1cm4gdGhpcykuIElmIHNvLCB0aGVuIGRvbid0IHVzZSB0aGUg b3B0aW9uIChhdCBsZWFzdCBvbiB0aGUgc2VydmVyIGZvciB0aGUgcG9vbHMpLg0KDQpJIHRoaW5r IHlvdXIgcmVxdWVzdCBpcyBkaWZmZXJlbnQgdGhhbiB0aGlzIGlwdjYtb25seSBvcHRpb24uIFNv LCBpZiB5b3UgZmVlbCB0aGF0IHNvbWV0aGluZyBpcyBuZWVkZWQsIGZlZWwgZnJlZSB0byB3cml0 ZSBhIGRyYWZ0IChsaWtlbHkgaXQgd291bGQgcmVxdWlyZSBhIG5ldyBvcHRpb24gdGhhdCB0aGUg c2VydmVyIGlzIHRvbGQgdG8gZG8gdGhpcyBzcGVjaWFsIGJlaGF2aW9yKS4NCg0KLSBCZXJuaWUN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IA0KU2VudDogV2VkbmVzZGF5 LCBEZWNlbWJlciAxMSwgMjAxOSA3OjQ5IEFNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6 QGNpc2NvLmNvbT4NCkNjOiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+OyBkaGN3Z0Bp ZXRmLm9yZzsgVjYgT3BzIExpc3QgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtkaGN3 Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLXY2b25s eS0wMS50eHQNCg0KUmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0K DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBCZXJuaWUgVm9seiAodm9s eikgW21haWx0bzp2b2x6QGNpc2NvLmNvbV0gRW52b3nDqcKgOiBtZXJjcmVkaSAxMSANCj4gZMOp Y2VtYnJlIDIwMTkgMTI6MjAgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiBDY8KgOiBK ZW4gTGlua292YTsgDQo+IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlzdCBPYmpldMKgOiBSZTog W2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIA0KPiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmst ZGhjLSB2Nm9ubHktMDEudHh0DQo+IA0KPiBOb3Qgc3VyZSBob3cgdGhpcyBpcyBzdXBwb3NlZCB0 byB3b3JrIHRvZGF5IChpcyB0aGlzIGRvY3VtZW50ZWQgc29tZXdoZXJlKT8NCj4gSXMgZGhjcCBz ZXJ2ZXIgYWxyZWFkeSBhc3NpZ25pbmcgYWRkcmVzc2VzIGluIHRoZSBzcGVjaWFsIHJhbmdlPw0K DQpbTWVkXSBESENQIHNlcnZlcnMgYXJlIG5vdCB1c2VkIHRvZGF5IHRvIGFzc2lnbiB0aGVzZSBh ZGRyZXNzZXMuIFRoZSBzZWxlY3Rpb24gb2YgdGhlIGFkZHJlc3MgaXMgbG9jYWwgdG8gdGhlIGhv c3QuIFRoZXJlIGlzIG5vIGFtYmlndWl0eSBmb3Igc29tZSBJUHY0YWFTIHRlY2huaXF1ZXMgKERT LUxpdGUgdXNlcyAxOTIuMC4wLjIpIGJ1dCBub3QgZm9yIENMQVQgKDE5Mi4wLjAuMC8yOSkuDQoN CiBJZiBzbywgd2h5DQo+IG5vdCBjb250aW51ZSB0aGF0IHByYWN0aWNlIGFuZCBkb27igJl0IGhv bm9yIHRoZSBpcHY2LW9ubHkgb3B0aW9uIG9uIHNlcnZlci4NCg0KW01lZF0gVGhhdCB3b3VsZG4n dCB3b3JrIGJlY2F1c2UgbXkgcHJvcG9zYWwgaXMgZm9yIHRoZSBzZXJ2ZXIgdG8gcmV0dXJuIHRo ZSAqKiBzYW1lICoqIGFkZHJlc3MgdG8gYWxsIHJlcXVlc3RpbmcgaG9zdHMgd2l0aCBpcHY2LW9u bHkgZW5hYmxlZC4gVGhhdCBhZGRyZXNzIHdpbGwgYmUgcGFzc2VkIHRvIG1vZHVsZXMgc3VjaCBh cyBDTEFULiBUaGlzIGJlaGF2aW9yIGlzIGFscmVhZHkgcmVxdWlyZWQgYnkgdGhpcyBkcmFmdDog DQoNCiAgIEFzIGFuIG9wdGlvbmFsIG9wdGltaXphdGlvbiBhbiBJUHY2LW1vc3RseSBwb29sIE1B WSBiZSBjb25maWd1cmVkDQogICB3aXRoIGEgZGVkaWNhdGVkIElQdjQgYWRkcmVzcyB0byBiZSBy ZXR1cm5lZCB0byBJUHY2LW9ubHkgY2FwYWJsZQ0KICAgY2xpZW50cy4gIEluIHRoYXQgY2FzZSB0 aGUgc2VydmVyIFNIT1VMRCBzcGVjaWZ5IHRoYXQgYWRkcmVzcyBhcyB0aGUNCiAgIGNsaWVudCdz IG5ldHdvcmsgYWRkcmVzcyBhbmQgTVVTVCBOT1QgdmVyaWZ5IGl0cyB1bmlxdWVuZXNzLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl4NCg0KVGhlIHZhbHVlIEkgc2VlIGluIHJldHVybmluZyBhbiBhZGRyZXNzIGZyb20gdGhpcyB3 ZWxsLWtub3duIHJhbmdlIGlzIHRoYXQgdGhlIGhvc3QgZG9lcyBub3QgZXZlbiBuZWVkIHRvIHBh dXNlLCBpLmUuLCB0aGlzIHRleHQgd29uJ3QgYmUgcmVxdWlyZWQgYW55bW9yZSBpbiB0aGUgZHJh ZnQ6IA0KDQo9PQ0KSWYgdGhlDQogICBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiByZXR1cm5l ZCBieSB0aGUgc2VydmVyIGNvbnRhaW5zIG5vbi16ZXJvDQogICB2YWx1ZSB0aGUgY2xpZW50IFNI T1VMRCBzZXQgdGhlIFY2T05MWV9XQUlUIHRpbWVyIHRvIHRoYXQgdmFsdWUuICBJZg0KICAgdGhl IHNlcnZlciByZXR1cm5zIHplcm8gdmFsdWUgdGhlIGNsaWVudCBNVVNUIHVzZSBpdHMgb3duDQog ICBjb25maWd1cmF0aW9uIGZvciBWNk9OTFlfV0FJVCB0aW1lci4gIFRoZSBjbGllbnQgU0hPVUxE IHN0b3AgdGhlIERIQ1ANCiAgIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyBmb3IgYXQgbGVhc3QgVjZP TkxZX1dBSVQgc2Vjb25kcyBvciB1bnRpbCBhDQogICBuZXR3b3JrIGF0dGFjaG1lbnQgZXZlbnQg aGFwcGVucy4gIFRoZSBob3N0IE1BWSBkaXNhYmxlIElQdjQgc3RhY2sNCiAgIGNvbXBsZXRlbHkg Zm9yIFY2T05MWV9XQUlUIHNlY29uZHMgb3IgdW50aWwgdGhlIG5ldHdvcmsgZGlzY29ubmVjdGlv bg0KICAgZXZlbnQgaGFwcGVucy4NCj09DQoNClRoZSBob3N0IHdvbid0IGVtaXQgSVB2NCBwYWNr ZXRzICJvbiB0aGUgd2lyZSIgd2hlbiBhc3NpZ25lZCB3aXRoIHN1Y2ggYWRkcmVzcy4NCg0KPiAN Cj4gLSBCZXJuaWUNCj4gDQo+ID4gT24gRGVjIDExLCAyMDE5LCBhdCAxOjI4IEFNLCAibW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSINCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ IHdyb3RlOg0KPiA+DQo+ID4g77u/SGkgQmVybmllLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxp bmUuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4+IERlIDogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBj aXNjby5jb21dIEVudm95w6kgOiBtYXJkaSAxMCANCj4gPj4gZMOpY2VtYnJlIDIwMTkgMTc6MTEg w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBKZW4gTGlua292YTsgDQo+ID4+IGRoY3dn QGlldGYub3JnIENjIDogVjYgT3BzIExpc3QgT2JqZXQgOiBSRTogW2RoY3dnXSBGd2Q6IE5ldyAN Cj4gPj4gVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLSB2Nm9ubHktMDEu dHh0DQo+ID4+DQo+ID4+IEhpOg0KPiA+Pg0KPiA+PiBJcyAoOCk6DQo+ID4+DQo+ID4+ICAgICg4 KSBDb25zaWRlciByZXR1cm5pbmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVkIGlu IA0KPiA+PiBSRkM3MzM1IGZvciBJUHY2LW9ubHkgaG9zdHMuIFN1Y2ggSVB2NCBhZGRyZXNzZXMg YXJlIHJlcXVpcmVkIA0KPiA+PiBhbnl3YXkgZm9yIHNvbWUNCj4gSVB2Ni0NCj4gPj4gb25seSBo b3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0KPiA+Pg0KPiA+PiAgICA9PT09 DQo+ID4+ICAgICAgIFRoZSByZXN1bHQgaXMgdGhhdCAxOTIuMC4wLjAvMjkgbWF5IGJlIHVzZWQg aW4gYW55IHN5c3RlbQ0KPiA+PiAgICAgICB0aGF0IHJlcXVpcmVzIElQdjQgYWRkcmVzc2VzIGZv ciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggSVB2NA0KPiA+PiAgICAgICBjb21tdW5pY2F0 aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0IA0KPiA+ PiBwYWNrZXRzDQo+ID4+ICAgICAgICJvbiB0aGUgd2lyZSIuDQo+ID4+ICAgID09PT0NCj4gPj4N Cj4gPj4gQnV0IFJGQzczMzUgc2F5cyAoaW4gc2VjdGlvbiA0KToNCj4gPj4NCj4gPj4gICBJQU5B IGhhcyBkZWZpbmVkIGEgd2VsbC1rbm93biByYW5nZSwgMTkyLjAuMC4wLzI5LCBpbiBbUkZDNjMz M10sDQo+ID4+ICAgd2hpY2ggaXMgZGVkaWNhdGVkIGZvciBEUy1MaXRlLiAgQXMgZGVmaW5lZCBp biBbUkZDNjMzM10sIHRoaXMgc3VibmV0DQo+ID4+ICAgaXMgb25seSBwcmVzZW50IGJldHdlZW4g dGhlIEI0IGFuZCB0aGUgQWRkcmVzcyBGYW1pbHkgVHJhbnNpdGlvbg0KPiA+PiAgIFJvdXRlciAo QUZUUikgYW5kIG5ldmVyIGVtaXRzIHBhY2tldHMgZnJvbSB0aGlzIHByZWZpeCAib24gdGhlIHdp cmUiLg0KPiA+PiA8LS0tDQo+ID4+ICAgNDY0WExBVCBoYXMgdGhlIHNhbWUgbmVlZCBmb3IgYSBu b24tcm91dGVkIElQdjQgcHJlZml4LCBhbmQgdGhpcyBzYW1lDQo+ID4+ICAgbmVlZCBtYXkgYmUg Y29tbW9uIGZvciBvdGhlciBzaW1pbGFyIHNvbHV0aW9ucy4gIEl0IGlzIG1vc3QgcHJ1ZGVudA0K PiA+PiAgIGFuZCBlZmZlY3RpdmUgdG8gZ2VuZXJhbGl6ZSAxOTIuMC4wLjAvMjkgZm9yIHRoZSB1 c2Ugb2Ygc3VwcG9ydGluZw0KPiA+PiAgIElQdjQgaW50ZXJmYWNlcyBpbiBJUHY2IHRyYW5zaXRp b24gdGVjaG5vbG9naWVzIHJhdGhlciB0aGFuIHJlc2VydmluZw0KPiA+PiAgIGEgcHJlZml4IGZv ciBldmVyeSBwb3NzaWJsZSBzb2x1dGlvbi4NCj4gPj4NCj4gPj4gU28sIHRoaXMgYWRkcmVzcyBp cyBvbmx5IHVzZWQgIm9uIHRoZSBob3N0IiAobm90IG9uIHRoZSB3aXJlKSwgc28gDQo+ID4+IHdo eQ0KPiB3b3VsZA0KPiA+PiB0aGVyZSBiZSBhbnkgbmVlZCBmb3IgdGhlIERIQ1Agc2VydmVyIHRv IGFzc2lnbiB0aGlzIGFkZHJlc3M/DQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlzIHRvIGVhc2UgcmVt b3RlIHRyb3VibGVzaG9vdGluZyBvZiB0aGUgSVB2NGFhUyANCj4gPiBjb21wb25lbnQNCj4gKENM QVQsIEI0KSBvZiB0aGUgSVB2Ni1vbmx5IGhvc3QuIENvbnRyb2xsaW5nIHRoZSBJUHY0IGFkZHJl c3MgDQo+IGNvbmZpZ3VyZWQgbG9jYWxseSBhbGxvd3MgdG8gbWFrZSB1c2Ugb2YgdG9vbHMgc3Vj aCBhcyBQUk9CRQ0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgzMzUpIHRvIHJl bW90ZWx5IGFzc2VzcyB0aGUgc3RhdHVzIG9mIA0KPiB0aGUgSVB2NGFhUyBjb21wb25lbnQgdmlh IGFuIElQdjYgbmV0d29yay4NCj4gPg0KPiA+Pg0KPiA+PiBBbmQgYXMgdGhlIElQdjYtb25seSBv cHRpb24gbWVhbnMgdGhhdCB0aGUgaG9zdCBuZXZlciBjb21wbGV0ZXMgdGhlIA0KPiA+PiBESENQ RElTQ09WRVIvT0ZGRVIvUkVRVUVTVC9BQ0sgKHN0b3BzIGF0IE9GRkVSKSwgdGhpcyB3b3JrIGNv dWxkIA0KPiA+PiBub3QgYmUgdXNlZCB0byBhc3NpZ24gYW55IGFkZHJlc3MuDQo+ID4+DQo+ID4+ IC0gQmVybmllDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IGRoY3dnIDxkaGN3Zy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgDQo+ID4+IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIg MTAsIDIwMTkgNTozMiBBTQ0KPiA+PiBUbzogSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29t PjsgZGhjd2dAaWV0Zi5vcmcNCj4gPj4gQ2M6IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4N Cj4gPj4gU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIA0KPiA+PiBkcmFmdC1saW5rLWRoYy0gdjZvbmx5LTAxLnR4dA0KPiA+Pg0KPiA+PiBIaSBK ZW4sDQo+ID4+DQo+ID4+IFRoYW5rIHlvdSBmb3Igc2hhcmluZyB0aGlzIHVwZGF0ZWQgdmVyc2lv bi4gQmVsb3cgc29tZSBwb2ludHMgdGhhdCANCj4gPj4gSSBkbyB0aGluayBuZWVkIG1vcmUgY2xh cmlmaWNhdGlvbiBpbiB0aGUgSS1EOg0KPiA+Pg0KPiA+PiAoMSkgVGhlIGRvY3VtZW50IGlzIHRv byBOQVQ2NCBjZW50cmljLiBUaGUgcHJvcG9zYWwgbWF5IGFwcGx5IGFzIA0KPiA+PiB3ZWxsDQo+ IGZvcg0KPiA+PiBvdGhlciBJUHY2LW9ubHkgZGVwbG95bWVudCBzY2VuYXJpb3MgKHR5cGljYWxs eSwgdW5tYW5hZ2VkIA0KPiA+PiBJUHY2LW9ubHkNCj4gQ1BFcw0KPiA+PiB3aXRoIElQdjRhYVMp Lg0KPiA+Pg0KPiA+PiAoMikgQSBkaXNjdXNzaW9uIG9uIHRoZSBiZW5lZml0IG9mIHRoaXMgZXh0 cmEgc2lnbmFsIGNvbXBhcmVkIHRvIA0KPiA+PiByZWx5aW5nDQo+IG9uDQo+ID4+IGV4aXN0aW5n IHNpZ25hbHMgKHByZWY2NCwgYWZ0cl9uYW1lLCBtYXBfY29udGFpbmVyLi4uKS4gRm9yIA0KPiA+ PiBleGFtcGxlLCBhDQo+IGhvc3QNCj4gPj4gdGhhdCBzdXBwb3J0cyB0aGUgb3B0aW9uIGlzIHJl YWR5IHRvIHdhaXQgYXQgbWluaW11bSAzMDBzIGFuZCANCj4gPj4gZGlzYWJsZQ0KPiBpdHMNCj4g Pj4gSVB2NCBjb25maWd1cmF0aW9uIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBpcyBoYXBwZW5pbmcgb24g dGhlIElQdjYgbGVnLiANCj4gPj4gSG93DQo+IGlzDQo+ID4+IHRoYXQgc3VwZXJpb3IgdG8gYSBo b3N0IGRlbGF5aW5nIERIQ1AgcHJvY2VzcyBieSB4eHggbXMgc2hvdWxkIGJlDQo+IGV4cGxhaW5l ZA0KPiA+PiBmdXJ0aGVyLg0KPiA+Pg0KPiA+PiAoMykgSG93ICJJUHY2LW9ubHkgcHJlZmVycmVk IiBtb2RlIGlzIHN1cHBvc2VkIHRvIGJlIHNldCBhdCB0aGUgDQo+ID4+IGhvc3QNCj4gc2lkZToN Cj4gPj4NCj4gPj4gPT0NCj4gPj4gICBBIERIQ1AgY2xpZW50IFNIT1VMRCBhbGxvdyBhIGRldmlj ZSBhZG1pbmlzdHJhdG9yIHRvIGNvbmZpZ3VyZQ0KPiA+PiAgIElQdjYtb25seSBwcmVmZXJyZWQg bW9kZSBlaXRoZXIgZm9yIGEgc3BlY2lmaWMgaW50ZXJmYWNlICh0byBpbmRpY2F0ZQ0KPiA+PiAg IHRoYXQgdGhlIGRldmljZSBpcyBJUHY2LW9ubHkgY2FwYWJsZSBpZiBjb25uZWN0ZWQgdG8gYSBO QVQ2NCBuZXR3b3JrDQo+ID4+ICAgdmlhIHRoYXQgaW50ZXJmYWNlKSBvciBmb3IgYWxsIGludGVy ZmFjZXMuDQo+ID4+ID09DQo+ID4+DQo+ID4+ICogSSBndWVzcyB0aGUgZGVmYXVsdCB2YWx1ZSB3 aGVuIHRoZSBvcHRpb24gaXMgc3VwcG9ydGVkIGJ5IGEgaG9zdCANCj4gPj4gaXMgdG8gZGlzYWJs ZSBpbmNsdWRpbmcgaXQgaW4gdGhlIHJlcXVlc3QuIFRoZSBkb2N1bWVudCBzaG91bGQgDQo+ID4+ IGluY2x1ZGUgYSBkaXNjdXNzaW9uIG9uIHRoZSBkZWZhdWx0IGJlaGF2aW9yLg0KPiA+PiAqIElm IGFuIGV4cGxpY2l0IGFjdGlvbiBpcyBuZWVkZWQgZnJvbSB0aGUgdXNlciB0byBlbmFibGUgaW5j bHVkaW5nIA0KPiA+PiB0aGUgb3B0aW9uLCBoYXZpbmcgYSBkaXNjdXNzaW9uIHRvIHdoYXQgZXh0 ZW50IHRoZSBmZWF0dXJlIGlzIA0KPiA+PiBsaWtlbHkgdG8gYmUgZW5hYmxlZCB3b3VsZCBiZSBu ZWVkZWQuDQo+ID4+DQo+ID4+ICg0KSBUaGUgZG9jdW1lbnQgaXMgc3RpbGwgbWl4aW5nIHRoZSBE SENQIGNsaWVudCB2cy4gaG9zdCANCj4gPj4gYmVoYXZpb3JzLiBGb3IgZXhhbXBsZSwNCj4gPj4N Cj4gPj4gICBDbGllbnRzIG5vdCBjYXBhYmxlIG9mIG9wZXJhdGluZyBpbiBhbiBJUHY2LW9ubHkg TkFUNjQgZW52aXJvbm1lbnQNCj4gPj4gICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl4NCj4gPj4gICBNVVNUIE5PVCBpbmNsdWRlIHRoZSBJUHY2LW9ubHkg UHJlZmVycmVkIG9wdGlvbiBpbiB0aGUgUGFyYW1ldGVyDQo+ID4+ICAgUmVxdWVzdCBMaXN0IG9m IGFueSBESENQIHBhY2tldHMgYW5kIE1VU1QgaWdub3JlIHRoYXQgb3B0aW9uIGluDQo+ID4+ICAg cGFja2V0cyByZWNlaXZlZCBmcm9tIERIQ1Agc2VydmVycy4NCj4gPj4NCj4gPj4gZG9lcyBub3Qg bWFrZSBzZW5zZSBmb3IgYSBESENQIGNsaWVudC4NCj4gPj4NCj4gPj4gQWxzbywgaG93IHRoZSBo b3N0IGlzIGFibGUgdG8gYXNzZXNzL2RldGVybWluZSB0aGF0IGl0IGlzIChub3QpIA0KPiA+PiBj YXBhYmxlDQo+IHRvDQo+ID4+IGJlaGF2ZSBpbiB0aGUgSVB2NiBtb2RlPw0KPiA+Pg0KPiA+PiAo NSkgVGhlIGRlZmluaXRpb24gb2YgSVB2NGFhUyBpcyBub3QgYWxpZ25lZCB3aXRoIG90aGVyIFJG Q3M6IGUuZy4sDQo+IFJGQzg1ODUNCj4gPj4gc2F5cyB0aGUgZm9sbG93aW5nOg0KPiA+Pg0KPiA+ PiAgICJJUHY0YWFTIiBzdGFuZHMgZm9yICJJUHY0LWFzLWEtU2VydmljZSIsIG1lYW5pbmcgdHJh bnNpdGlvbg0KPiA+PiAgIHRlY2hub2xvZ2llcyBmb3IgZGVsaXZlcmluZyBJUHY0IGluIElQdjYt b25seSBjb25uZWN0aXZpdHkuDQo+ID4+DQo+ID4+IFdoaWxlIHlvdXJzIGlzOg0KPiA+Pg0KPiA+ PiAgIElQdjQtYXMtYS1TZXJ2aWNlOiBhIGRlcGxveW1lbnQgc2NlbmFyaW8gd2hlbiBlbmQgaG9z dHMgYXJlIGV4cGVjdGVkDQo+ID4+ICAgdG8gb3BlcmF0ZSBpbiBJUHY2LW9ubHkgbW9kZSBieSBk ZWZhdWx0IGFuZCBJUHY0IGFkZHJlc3NlcyBjYW4gYmUNCj4gPj4gICBhc3NpZ25lZCB0byBzb21l IGhvc3RzIGlmIHRob3NlIGhvc3RzIGV4cGxpY2l0bHkgb3B0LWluIHRvIHJlY2VpdmluZw0KPiA+ PiAgIElQdjQgYWRkcmVzc2VzLg0KPiA+Pg0KPiA+PiAoNikgRG8geW91IGNvbnNpZGVyIGEgaG9z dCB3aXRoIENMQVQgZnVuY3Rpb24gYXMgYW4gSVB2Ni1vbmx5IGhvc3Q/DQo+ID4+DQo+ID4+IElm IHNvLCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gc2hvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXIg dG8gIklQdjQgDQo+ID4+IGNvbm5lY3Rpdml0eSIgcmF0aGVyIHRoYW4gIklQdjQiIGluIGdlbmVy YWwuIFRoaXMgaXMgYmVjYXVzZSBhbiANCj4gPj4gSVB2NCBhZGRyZXNzIGlzIHJlcXVpcmVkIGZv ciBDTEFUIGZvciBleGFtcGxlLg0KPiA+Pg0KPiA+PiA9PQ0KPiA+PiAgIElQdjYtb25seSBjYXBh YmxlIGhvc3Q6IGEgaG9zdCB3aGljaCBkb2VzIG5vdCByZXF1aXJlIElQdjQgYW5kIGNhbg0KPiA+ PiAgIG9wZXJhdGUgb24gSVB2Ni1vbmx5IG5ldHdvcmtzLg0KPiA+PiA9PQ0KPiA+Pg0KPiA+PiAo NykgV291bGRuJ3QgdGhlIGZvbGxvd2luZyBhZGQgYW4gZXh0cmEgZGVsYXkgZm9yIGFwcGxpY2F0 aW9ucyANCj4gPj4gcmVxdWlyaW5nIENMQVQ/DQo+ID4+DQo+ID4+ID09DQo+ID4+IFRoZSBob3N0 IE1BWSBkaXNhYmxlIElQdjQgc3RhY2sNCj4gPj4gICBjb21wbGV0ZWx5IGZvciBWNk9OTFlfV0FJ VCBzZWNvbmRzIG9yIHVudGlsIHRoZSBuZXR3b3JrIGRpc2Nvbm5lY3Rpb24NCj4gPj4gICBldmVu dCBoYXBwZW5zLg0KPiA+PiA9PQ0KPiA+Pg0KPiA+PiAoOCkgQ29uc2lkZXIgcmV0dXJuaW5nIGFu IGFkZHJlc3MgZnJvbSB0aGUgcmFuZ2UgZGVmaW5lZCBpbiBSRkM3MzM1IA0KPiA+PiBmb3IgSVB2 Ni1vbmx5IGhvc3RzLiBTdWNoIElQdjQgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCBhbnl3YXkgZm9y IA0KPiA+PiBzb21lIElQdjYtDQo+IG9ubHkNCj4gPj4gaG9zdHMgKHRob3NlIHdpdGggYSBDTEFU IGZvciBleGFtcGxlKS4NCj4gPj4NCj4gPj4gPT09PQ0KPiA+PiAgIFRoZSByZXN1bHQgaXMgdGhh dCAxOTIuMC4wLjAvMjkgbWF5IGJlIHVzZWQgaW4gYW55IHN5c3RlbQ0KPiA+PiAgIHRoYXQgcmVx dWlyZXMgSVB2NCBhZGRyZXNzZXMgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBJUHY0 DQo+ID4+ICAgY29tbXVuaWNhdGlvbnMgaW4gYW4gSVB2Ni1vbmx5IG5ldHdvcmsgYnV0IGRvZXMg bm90IGVtaXQgSVB2NCBwYWNrZXRzDQo+ID4+ICAgIm9uIHRoZSB3aXJlIi4NCj4gPj4gPT09PQ0K PiA+Pg0KPiA+PiBDaGVlcnMsDQo+ID4+IE1lZA0KPiA+Pg0KPiA+Pj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+ID4+PiBEZSA6IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZSBKZW4gDQo+ID4+PiBMaW5rb3ZhIEVudm95w6kgOiBtYXJkaSAx MCBkw6ljZW1icmUgMjAxOSAwMTowMiDDgCA6IGRoY3dnQGlldGYub3JnIA0KPiA+Pj4gQ2MgOiBW NiBPcHMgTGlzdCBPYmpldCA6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yDQo+ID4+PiBkcmFmdC1saW5rLWRoYy12Nm9ubHktIDAxLnR4dA0KPiA+Pj4NCj4gPj4+IEhl bGxvLA0KPiA+Pj4NCj4gPj4+IFRoYW5rcyB0byBldmVyeW9uZSBmb3IgdmVyeSBwcm9kdWN0aXZl IGNlbnRpLXRocmVhZCBvbg0KPiA+Pj4gZHJhZnQtbGluay1kaGMtdjZvbmx5LTAwIDspDQo+ID4+ PiBIZXJlIGlzIHRoZSBpbXByb3ZlZCB2ZXJzaW9uLCAtMDEuDQo+ID4+Pg0KPiA+Pj4gVGhlIG1h aW4gY2hhbmdlczoNCj4gPj4+DQo+ID4+PiAtIFRoZSBvcHRpb24gaXMgbm90IHplcm8gbGVuZ3Ro IGFueW1vcmUuIEl0IGhhcyA0LWJ5dGVzIHZhbHVlIA0KPiA+Pj4gd2hpY2ggbWlnaHQgY29udGFp biBWNk9OTFlfV0FJVCB0aW1lci4gQmVuZWZpdHM6DQo+ID4+PiAgICAtLS0gYWxsb3dzIHRoZSBu ZXR3b3JrIGFkbWluaXN0cmF0b3JzIHRvIHBpbG90IHRoZSBjaGFuZ2VzIGFuZCANCj4gPj4+IHJv bGxiYWNrIHF1aWNrbHkgaWYgbmVlZGVkOw0KPiA+Pj4gICAgLS0tIGFkZHJlc3NlZCBzb21lIGNv bmNlcm4gYWJvdXQgYW4gb3B0aW9uIGhhdmluZyB6ZXJvIGxlbmd0aCANCj4gPj4+IChhbGxlZ2Vk bHkgaXQgbWlnaHQgY29uZnVzZSBzb21lIGNsaWVudHMpDQo+ID4+Pg0KPiA+Pj4gLSBVc2luZyBh IGRlZGljYXRlZCBhZGRyZXNzIHRvIHJldHVybiB0byBjbGllbnRzIGlzIG5vdyBhbiANCj4gPj4+ IG9wdGlvbmFsIG9wdGltaXNhdGlvbi4gQnkgZGVmYXVsdCB0aGUgc2VydmVyIGlzIGV4cGVjdGVk IGp1c3QgdG8gDQo+ID4+PiByZXR1cm4gYSByYW5kb20gYWRkcmVzcyAoYXMgdXN1YWwpLg0KPiA+ Pj4NCj4gPj4+IC0gVHlwb3MgZml4ZWQgKHByb2JhYmx5IHNvbWUgbmV3IHR5cG9zIGFkZGVkIHRo b3VnaCkuDQo+ID4+Pg0KPiA+Pj4gVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0aGUgREhDIFdHIHRv IGNvbnNpZGVyIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuDQo+ID4+Pg0KPiA+Pj4gVGhhbmsgeW91 IQ0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQo+ ID4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+Pj4gRGF0ZTogVHVlLCBE ZWMgMTAsIDIwMTkgYXQgMTA6NDQgQU0NCj4gPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPiA+Pj4gVG86IFRvbWVr IE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+LCBMb3JlbnpvIENvbGl0dGkg DQo+ID4+PiA8bG9yZW56b0Bnb29nbGUuY29tPiwgSmVuIExpbmtvdmEgPGZ1cnJ5QGdvb2dsZS5j b20+LCBNaWNoYWVsIEMuDQo+ID4+PiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bGluay1kaGMtdjZvbmx5LTAxLnR4dCBoYXMgYmVlbiANCj4gPj4+IHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgSmVuIExpbmtvdmEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj4gPj4+IHJlcG9z aXRvcnkuDQo+ID4+Pg0KPiA+Pj4gTmFtZTogICAgICAgICAgIGRyYWZ0LWxpbmstZGhjLXY2b25s eQ0KPiA+Pj4gUmV2aXNpb246ICAgICAgIDAxDQo+ID4+PiBUaXRsZTogICAgICAgICAgSVB2Ni1P bmx5LVByZWZlcnJlZCBPcHRpb24gZm9yIERIQ1ANCj4gPj4+IERvY3VtZW50IGRhdGU6ICAyMDE5 LTEyLTA5DQo+ID4+PiBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4+ PiBQYWdlczogICAgICAgICAgMTANCj4gPj4+IFVSTDoNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0DQo+ID4+PiBT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGlu ay1kaGMtdjZvbmx5Lw0KPiA+Pj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDENCj4gPj4+IEh0bWxpemVkOiAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbmstZGhjLQ0KPiA+ PiB2Nm9ubHkNCj4gPj4+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtbGluay1kaGMtDQo+IHY2b25seS0NCj4gPj4gMDENCj4gPj4+DQo+ID4+ PiBBYnN0cmFjdDoNCj4gPj4+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBESENQIG9wdGlv biB0byBpbmRpY2F0ZSB0aGF0IGEgaG9zdA0KPiA+Pj4gICBzdXBwb3J0cyBhbiBJUHY2LW9ubHkg bW9kZSBhbmQgd2lsbGluZyB0byBmb3JnbyBvYnRhaW5pbmcgYW4gSVB2NA0KPiA+Pj4gICBhZGRy ZXNzIGlmIHRoZSBuZXR3b3JrIHByb3ZpZGVzIElQdjYgY29ubmVjdGl2aXR5Lg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPiA+Pj4gc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IA0KPiA+Pj4g dG9vbHMuaWV0Zi5vcmcuDQo+ID4+Pg0KPiA+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gLS0NCj4gPj4+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gPj4+ DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+Pj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ID4+PiBkaGN3Z0BpZXRmLm9yZw0KPiA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBkaGN3ZyBt YWlsaW5nIGxpc3QNCj4gPj4gZGhjd2dAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From nobody Wed Dec 11 06:13:10 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B3120041; Wed, 11 Dec 2019 06:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SWVCcAMgUeH; Wed, 11 Dec 2019 06:13:00 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C91E12000F; Wed, 11 Dec 2019 06:13:00 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 47XzRG6Clyz1yqY; Wed, 11 Dec 2019 15:12:58 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 47XzRG5cj8z1xpN; Wed, 11 Dec 2019 15:12:58 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Wed, 11 Dec 2019 15:12:58 +0100 From: To: "Bernie Volz (volz)" CC: Jen Linkova , "dhcwg@ietf.org" , "V6 Ops List" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt Thread-Index: AQHVr3RzQk/hbqRR3Uuq2dMGLakzfKe0c/9wgABW+RSAAAwR4IAAFzbAgAAJHiA= Date: Wed, 11 Dec 2019 14:12:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330313E9101@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <157593507544.2098.9687007201578884820.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330313E7F6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> , <787AE7BB302AE849A7480A190F8B9330313E8BE7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1BDB5CA6-4A86-47D7-9D12-F7D427E3F76A@cisco.com> <787AE7BB302AE849A7480A190F8B9330313E8E97@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 14:13:03 -0000 UmUtLA0KDQpUaGUgZHJhZnQgc2F5cyB0aGUgZm9sbG93aW5nOiANCg0KICAgVGhlIGNsaWVudCBT SE9VTEQgc3RvcCB0aGUgREhDUA0KICAgY29uZmlndXJhdGlvbiBwcm9jZXNzIGZvciBhdCBsZWFz dCBWNk9OTFlfV0FJVCBzZWNvbmRzIG9yIHVudGlsIGENCiAgIG5ldHdvcmsgYXR0YWNobWVudCBl dmVudCBoYXBwZW5zLg0KDQpXaGlsZSBJIGludGVycHJldCB5b3VyIHJlc3BvbnNlIGFzOiANCg0K ICAgVGhlIGNsaWVudCBNVVNUIHN0b3AgdGhlIERIQ1ANCiAgIGNvbmZpZ3VyYXRpb24gcHJvY2Vz cyBmb3IgYXQgbGVhc3QgVjZPTkxZX1dBSVQgc2Vjb25kcyBvciB1bnRpbCBhDQogICBuZXR3b3Jr IGF0dGFjaG1lbnQgZXZlbnQgaGFwcGVucy4NCg0KQmVybmllLCBPSyB0byBjbG9zZSAoOCkgZnJv bSBteSBpbml0aWFsIHJldmlldyBsaXN0LiAgDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2 b2x6QGNpc2NvLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxMSBkw6ljZW1icmUgMjAxOSAx NDozMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IEplbiBMaW5r b3ZhOyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3QNCj4gT2JqZXTCoDogUkU6IFtkaGN3Z10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpbmstZGhjLQ0KPiB2Nm9u bHktMDEudHh0DQo+IA0KPiBNZWQ6DQo+IA0KPiBJZiB0aGlzIG9wdGlvbiBpcyBpbiBwbGF5LCBu byBhZGRyZXNzIGlzICJhc3NpZ25lZCIgdG8gdGhlIGNsaWVudCBhcyB0aGF0DQo+IHJlcXVpcmVz IHRoZSBESENQUkVRVUVTVC9ESENQQUNLIG1lc3NhZ2VzIGFuZCB0aGUgY2xpZW50ICJzdG9wcyIg YWZ0ZXIgYQ0KPiBESENQT0ZGRVIgaWYgdGhlIG9wdGlvbiB3YXMgcmV0dXJuZWQuIFNvLCB5b3Ug Y2FuJ3QgdXNlIHRoaXMgaWYgeW91IHdhbnQgdG8NCj4gYXNzaWduIGFuIGFkZHJlc3MuDQo+IA0K PiBJJ20gbm90IHN1cmUgd2hhdCBpcyBiZWluZyBkb25lIHRvZGF5Og0KPiAxKSBBcmUgeW91IHNh eWluZyB0aGVyZSBpcyBubyBzdXBwb3J0IGZvciB0aGlzIGluIERIQ1AuIElmIHNvLCB0aGVuIHRo aXMgaXMNCj4gbm90IHNvbWV0aGluZyB0aGF0IGNhbiBiZSB1c2VkIHRvIGFjdGl2YXRlIHRoaXMg c3VwcG9ydC4NCj4gMikgQXJlIHlvdSBzYXlpbmcgdGhhdCBpdCB3b3JrcyBmaW5lIGFzIGlzIHRv ZGF5IChzaW5jZSB0aGUgREhDUCBzZXJ2ZXIgY2FuDQo+IGJlIGNvbmZpZ3VyZWQgKHNvbWVob3cp IHRvIHJldHVybiB0aGlzKS4gSWYgc28sIHRoZW4gZG9uJ3QgdXNlIHRoZSBvcHRpb24NCj4gKGF0 IGxlYXN0IG9uIHRoZSBzZXJ2ZXIgZm9yIHRoZSBwb29scykuDQo+IA0KPiBJIHRoaW5rIHlvdXIg cmVxdWVzdCBpcyBkaWZmZXJlbnQgdGhhbiB0aGlzIGlwdjYtb25seSBvcHRpb24uIFNvLCBpZiB5 b3UNCj4gZmVlbCB0aGF0IHNvbWV0aGluZyBpcyBuZWVkZWQsIGZlZWwgZnJlZSB0byB3cml0ZSBh IGRyYWZ0IChsaWtlbHkgaXQgd291bGQNCj4gcmVxdWlyZSBhIG5ldyBvcHRpb24gdGhhdCB0aGUg c2VydmVyIGlzIHRvbGQgdG8gZG8gdGhpcyBzcGVjaWFsIGJlaGF2aW9yKS4NCj4gDQo+IC0gQmVy bmllDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50 OiBXZWRuZXNkYXksIERlY2VtYmVyIDExLCAyMDE5IDc6NDkgQU0NCj4gVG86IEJlcm5pZSBWb2x6 ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQo+IENjOiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFp bC5jb20+OyBkaGN3Z0BpZXRmLm9yZzsgVjYgT3BzIExpc3QNCj4gPHY2b3BzQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbGluay1kaGMtDQo+IHY2b25seS0wMS50eHQNCj4gDQo+IFJlLSwNCj4gDQo+IFBsZWFz ZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9s ekBjaXNjby5jb21dIEVudm95w6nCoDogbWVyY3JlZGkgMTENCj4gPiBkw6ljZW1icmUgMjAxOSAx MjoyMCDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIENjwqA6IEplbiBMaW5rb3ZhOw0K PiA+IGRoY3dnQGlldGYub3JnOyBWNiBPcHMgTGlzdCBPYmpldMKgOiBSZTogW2RoY3dnXSBGd2Q6 IE5ldyBWZXJzaW9uDQo+ID4gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saW5rLWRoYy0gdjZvbmx5 LTAxLnR4dA0KPiA+DQo+ID4gTm90IHN1cmUgaG93IHRoaXMgaXMgc3VwcG9zZWQgdG8gd29yayB0 b2RheSAoaXMgdGhpcyBkb2N1bWVudGVkDQo+IHNvbWV3aGVyZSk/DQo+ID4gSXMgZGhjcCBzZXJ2 ZXIgYWxyZWFkeSBhc3NpZ25pbmcgYWRkcmVzc2VzIGluIHRoZSBzcGVjaWFsIHJhbmdlPw0KPiAN Cj4gW01lZF0gREhDUCBzZXJ2ZXJzIGFyZSBub3QgdXNlZCB0b2RheSB0byBhc3NpZ24gdGhlc2Ug YWRkcmVzc2VzLiBUaGUNCj4gc2VsZWN0aW9uIG9mIHRoZSBhZGRyZXNzIGlzIGxvY2FsIHRvIHRo ZSBob3N0LiBUaGVyZSBpcyBubyBhbWJpZ3VpdHkgZm9yDQo+IHNvbWUgSVB2NGFhUyB0ZWNobmlx dWVzIChEUy1MaXRlIHVzZXMgMTkyLjAuMC4yKSBidXQgbm90IGZvciBDTEFUDQo+ICgxOTIuMC4w LjAvMjkpLg0KPiANCj4gIElmIHNvLCB3aHkNCj4gPiBub3QgY29udGludWUgdGhhdCBwcmFjdGlj ZSBhbmQgZG9u4oCZdCBob25vciB0aGUgaXB2Ni1vbmx5IG9wdGlvbiBvbg0KPiBzZXJ2ZXIuDQo+ IA0KPiBbTWVkXSBUaGF0IHdvdWxkbid0IHdvcmsgYmVjYXVzZSBteSBwcm9wb3NhbCBpcyBmb3Ig dGhlIHNlcnZlciB0byByZXR1cm4NCj4gdGhlICoqIHNhbWUgKiogYWRkcmVzcyB0byBhbGwgcmVx dWVzdGluZyBob3N0cyB3aXRoIGlwdjYtb25seSBlbmFibGVkLiBUaGF0DQo+IGFkZHJlc3Mgd2ls bCBiZSBwYXNzZWQgdG8gbW9kdWxlcyBzdWNoIGFzIENMQVQuIFRoaXMgYmVoYXZpb3IgaXMgYWxy ZWFkeQ0KPiByZXF1aXJlZCBieSB0aGlzIGRyYWZ0Og0KPiANCj4gICAgQXMgYW4gb3B0aW9uYWwg b3B0aW1pemF0aW9uIGFuIElQdjYtbW9zdGx5IHBvb2wgTUFZIGJlIGNvbmZpZ3VyZWQNCj4gICAg d2l0aCBhIGRlZGljYXRlZCBJUHY0IGFkZHJlc3MgdG8gYmUgcmV0dXJuZWQgdG8gSVB2Ni1vbmx5 IGNhcGFibGUNCj4gICAgY2xpZW50cy4gIEluIHRoYXQgY2FzZSB0aGUgc2VydmVyIFNIT1VMRCBz cGVjaWZ5IHRoYXQgYWRkcmVzcyBhcyB0aGUNCj4gICAgY2xpZW50J3MgbmV0d29yayBhZGRyZXNz IGFuZCBNVVNUIE5PVCB2ZXJpZnkgaXRzIHVuaXF1ZW5lc3MuDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+IA0KPiBUaGUg dmFsdWUgSSBzZWUgaW4gcmV0dXJuaW5nIGFuIGFkZHJlc3MgZnJvbSB0aGlzIHdlbGwta25vd24g cmFuZ2UgaXMgdGhhdA0KPiB0aGUgaG9zdCBkb2VzIG5vdCBldmVuIG5lZWQgdG8gcGF1c2UsIGku ZS4sIHRoaXMgdGV4dCB3b24ndCBiZSByZXF1aXJlZA0KPiBhbnltb3JlIGluIHRoZSBkcmFmdDoN Cj4gDQo+ID09DQo+IElmIHRoZQ0KPiAgICBJUHY2LW9ubHkgUHJlZmVycmVkIG9wdGlvbiByZXR1 cm5lZCBieSB0aGUgc2VydmVyIGNvbnRhaW5zIG5vbi16ZXJvDQo+ICAgIHZhbHVlIHRoZSBjbGll bnQgU0hPVUxEIHNldCB0aGUgVjZPTkxZX1dBSVQgdGltZXIgdG8gdGhhdCB2YWx1ZS4gIElmDQo+ ICAgIHRoZSBzZXJ2ZXIgcmV0dXJucyB6ZXJvIHZhbHVlIHRoZSBjbGllbnQgTVVTVCB1c2UgaXRz IG93bg0KPiAgICBjb25maWd1cmF0aW9uIGZvciBWNk9OTFlfV0FJVCB0aW1lci4gIFRoZSBjbGll bnQgU0hPVUxEIHN0b3AgdGhlIERIQ1ANCj4gICAgY29uZmlndXJhdGlvbiBwcm9jZXNzIGZvciBh dCBsZWFzdCBWNk9OTFlfV0FJVCBzZWNvbmRzIG9yIHVudGlsIGENCj4gICAgbmV0d29yayBhdHRh Y2htZW50IGV2ZW50IGhhcHBlbnMuICBUaGUgaG9zdCBNQVkgZGlzYWJsZSBJUHY0IHN0YWNrDQo+ ICAgIGNvbXBsZXRlbHkgZm9yIFY2T05MWV9XQUlUIHNlY29uZHMgb3IgdW50aWwgdGhlIG5ldHdv cmsgZGlzY29ubmVjdGlvbg0KPiAgICBldmVudCBoYXBwZW5zLg0KPiA9PQ0KPiANCj4gVGhlIGhv c3Qgd29uJ3QgZW1pdCBJUHY0IHBhY2tldHMgIm9uIHRoZSB3aXJlIiB3aGVuIGFzc2lnbmVkIHdp dGggc3VjaA0KPiBhZGRyZXNzLg0KPiANCj4gPg0KPiA+IC0gQmVybmllDQo+ID4NCj4gPiA+IE9u IERlYyAxMSwgMjAxOSwgYXQgMToyOCBBTSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i DQo+ID4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+ID4NCj4gPiA+ IO+7v0hpIEJlcm5pZSwNCj4gPiA+DQo+ID4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+DQo+ ID4gPiBDaGVlcnMsDQo+ID4gPiBNZWQNCj4gPiA+DQo+ID4gPj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4gPj4gRGUgOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6QGNp c2NvLmNvbV0gRW52b3nDqSA6IG1hcmRpIDEwDQo+ID4gPj4gZMOpY2VtYnJlIDIwMTkgMTc6MTEg w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBKZW4gTGlua292YTsNCj4gPiA+PiBkaGN3 Z0BpZXRmLm9yZyBDYyA6IFY2IE9wcyBMaXN0IE9iamV0IDogUkU6IFtkaGN3Z10gRndkOiBOZXcN Cj4gPiA+PiBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGluay1kaGMtIHY2b25seS0w MS50eHQNCj4gPiA+Pg0KPiA+ID4+IEhpOg0KPiA+ID4+DQo+ID4gPj4gSXMgKDgpOg0KPiA+ID4+ DQo+ID4gPj4gICAgKDgpIENvbnNpZGVyIHJldHVybmluZyBhbiBhZGRyZXNzIGZyb20gdGhlIHJh bmdlIGRlZmluZWQgaW4NCj4gPiA+PiBSRkM3MzM1IGZvciBJUHY2LW9ubHkgaG9zdHMuIFN1Y2gg SVB2NCBhZGRyZXNzZXMgYXJlIHJlcXVpcmVkDQo+ID4gPj4gYW55d2F5IGZvciBzb21lDQo+ID4g SVB2Ni0NCj4gPiA+PiBvbmx5IGhvc3RzICh0aG9zZSB3aXRoIGEgQ0xBVCBmb3IgZXhhbXBsZSku DQo+ID4gPj4NCj4gPiA+PiAgICA9PT09DQo+ID4gPj4gICAgICAgVGhlIHJlc3VsdCBpcyB0aGF0 IDE5Mi4wLjAuMC8yOSBtYXkgYmUgdXNlZCBpbiBhbnkgc3lzdGVtDQo+ID4gPj4gICAgICAgdGhh dCByZXF1aXJlcyBJUHY0IGFkZHJlc3NlcyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRo DQo+IElQdjQNCj4gPiA+PiAgICAgICBjb21tdW5pY2F0aW9ucyBpbiBhbiBJUHY2LW9ubHkgbmV0 d29yayBidXQgZG9lcyBub3QgZW1pdCBJUHY0DQo+ID4gPj4gcGFja2V0cw0KPiA+ID4+ICAgICAg ICJvbiB0aGUgd2lyZSIuDQo+ID4gPj4gICAgPT09PQ0KPiA+ID4+DQo+ID4gPj4gQnV0IFJGQzcz MzUgc2F5cyAoaW4gc2VjdGlvbiA0KToNCj4gPiA+Pg0KPiA+ID4+ICAgSUFOQSBoYXMgZGVmaW5l ZCBhIHdlbGwta25vd24gcmFuZ2UsIDE5Mi4wLjAuMC8yOSwgaW4gW1JGQzYzMzNdLA0KPiA+ID4+ ICAgd2hpY2ggaXMgZGVkaWNhdGVkIGZvciBEUy1MaXRlLiAgQXMgZGVmaW5lZCBpbiBbUkZDNjMz M10sIHRoaXMNCj4gc3VibmV0DQo+ID4gPj4gICBpcyBvbmx5IHByZXNlbnQgYmV0d2VlbiB0aGUg QjQgYW5kIHRoZSBBZGRyZXNzIEZhbWlseSBUcmFuc2l0aW9uDQo+ID4gPj4gICBSb3V0ZXIgKEFG VFIpIGFuZCBuZXZlciBlbWl0cyBwYWNrZXRzIGZyb20gdGhpcyBwcmVmaXggIm9uIHRoZQ0KPiB3 aXJlIi4NCj4gPiA+PiA8LS0tDQo+ID4gPj4gICA0NjRYTEFUIGhhcyB0aGUgc2FtZSBuZWVkIGZv ciBhIG5vbi1yb3V0ZWQgSVB2NCBwcmVmaXgsIGFuZCB0aGlzDQo+IHNhbWUNCj4gPiA+PiAgIG5l ZWQgbWF5IGJlIGNvbW1vbiBmb3Igb3RoZXIgc2ltaWxhciBzb2x1dGlvbnMuICBJdCBpcyBtb3N0 IHBydWRlbnQNCj4gPiA+PiAgIGFuZCBlZmZlY3RpdmUgdG8gZ2VuZXJhbGl6ZSAxOTIuMC4wLjAv MjkgZm9yIHRoZSB1c2Ugb2Ygc3VwcG9ydGluZw0KPiA+ID4+ICAgSVB2NCBpbnRlcmZhY2VzIGlu IElQdjYgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgcmF0aGVyIHRoYW4NCj4gcmVzZXJ2aW5nDQo+ ID4gPj4gICBhIHByZWZpeCBmb3IgZXZlcnkgcG9zc2libGUgc29sdXRpb24uDQo+ID4gPj4NCj4g PiA+PiBTbywgdGhpcyBhZGRyZXNzIGlzIG9ubHkgdXNlZCAib24gdGhlIGhvc3QiIChub3Qgb24g dGhlIHdpcmUpLCBzbw0KPiA+ID4+IHdoeQ0KPiA+IHdvdWxkDQo+ID4gPj4gdGhlcmUgYmUgYW55 IG5lZWQgZm9yIHRoZSBESENQIHNlcnZlciB0byBhc3NpZ24gdGhpcyBhZGRyZXNzPw0KPiA+ID4N Cj4gPiA+IFtNZWRdIFRoaXMgaXMgdG8gZWFzZSByZW1vdGUgdHJvdWJsZXNob290aW5nIG9mIHRo ZSBJUHY0YWFTDQo+ID4gPiBjb21wb25lbnQNCj4gPiAoQ0xBVCwgQjQpIG9mIHRoZSBJUHY2LW9u bHkgaG9zdC4gQ29udHJvbGxpbmcgdGhlIElQdjQgYWRkcmVzcw0KPiA+IGNvbmZpZ3VyZWQgbG9j YWxseSBhbGxvd3MgdG8gbWFrZSB1c2Ugb2YgdG9vbHMgc3VjaCBhcyBQUk9CRQ0KPiA+IChodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODMzNSkgdG8gcmVtb3RlbHkgYXNzZXNzIHRoZSBz dGF0dXMgb2YNCj4gPiB0aGUgSVB2NGFhUyBjb21wb25lbnQgdmlhIGFuIElQdjYgbmV0d29yay4N Cj4gPiA+DQo+ID4gPj4NCj4gPiA+PiBBbmQgYXMgdGhlIElQdjYtb25seSBvcHRpb24gbWVhbnMg dGhhdCB0aGUgaG9zdCBuZXZlciBjb21wbGV0ZXMgdGhlDQo+ID4gPj4gREhDUERJU0NPVkVSL09G RkVSL1JFUVVFU1QvQUNLIChzdG9wcyBhdCBPRkZFUiksIHRoaXMgd29yayBjb3VsZA0KPiA+ID4+ IG5vdCBiZSB1c2VkIHRvIGFzc2lnbiBhbnkgYWRkcmVzcy4NCj4gPiA+Pg0KPiA+ID4+IC0gQmVy bmllDQo+ID4gPj4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZy b206IGRoY3dnIDxkaGN3Zy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiA+PiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPj4gU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMTAsIDIwMTkgNTozMiBBTQ0KPiA+ID4+IFRvOiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFp bC5jb20+OyBkaGN3Z0BpZXRmLm9yZw0KPiA+ID4+IENjOiBWNiBPcHMgTGlzdCA8djZvcHNAaWV0 Zi5vcmc+DQo+ID4gPj4gU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yDQo+ID4gPj4gZHJhZnQtbGluay1kaGMtIHY2b25seS0wMS50eHQNCj4gPiA+ Pg0KPiA+ID4+IEhpIEplbiwNCj4gPiA+Pg0KPiA+ID4+IFRoYW5rIHlvdSBmb3Igc2hhcmluZyB0 aGlzIHVwZGF0ZWQgdmVyc2lvbi4gQmVsb3cgc29tZSBwb2ludHMgdGhhdA0KPiA+ID4+IEkgZG8g dGhpbmsgbmVlZCBtb3JlIGNsYXJpZmljYXRpb24gaW4gdGhlIEktRDoNCj4gPiA+Pg0KPiA+ID4+ ICgxKSBUaGUgZG9jdW1lbnQgaXMgdG9vIE5BVDY0IGNlbnRyaWMuIFRoZSBwcm9wb3NhbCBtYXkg YXBwbHkgYXMNCj4gPiA+PiB3ZWxsDQo+ID4gZm9yDQo+ID4gPj4gb3RoZXIgSVB2Ni1vbmx5IGRl cGxveW1lbnQgc2NlbmFyaW9zICh0eXBpY2FsbHksIHVubWFuYWdlZA0KPiA+ID4+IElQdjYtb25s eQ0KPiA+IENQRXMNCj4gPiA+PiB3aXRoIElQdjRhYVMpLg0KPiA+ID4+DQo+ID4gPj4gKDIpIEEg ZGlzY3Vzc2lvbiBvbiB0aGUgYmVuZWZpdCBvZiB0aGlzIGV4dHJhIHNpZ25hbCBjb21wYXJlZCB0 bw0KPiA+ID4+IHJlbHlpbmcNCj4gPiBvbg0KPiA+ID4+IGV4aXN0aW5nIHNpZ25hbHMgKHByZWY2 NCwgYWZ0cl9uYW1lLCBtYXBfY29udGFpbmVyLi4uKS4gRm9yDQo+ID4gPj4gZXhhbXBsZSwgYQ0K PiA+IGhvc3QNCj4gPiA+PiB0aGF0IHN1cHBvcnRzIHRoZSBvcHRpb24gaXMgcmVhZHkgdG8gd2Fp dCBhdCBtaW5pbXVtIDMwMHMgYW5kDQo+ID4gPj4gZGlzYWJsZQ0KPiA+IGl0cw0KPiA+ID4+IElQ djQgY29uZmlndXJhdGlvbiByZWdhcmRsZXNzIG9mIHdoYXQgaXMgaGFwcGVuaW5nIG9uIHRoZSBJ UHY2IGxlZy4NCj4gPiA+PiBIb3cNCj4gPiBpcw0KPiA+ID4+IHRoYXQgc3VwZXJpb3IgdG8gYSBo b3N0IGRlbGF5aW5nIERIQ1AgcHJvY2VzcyBieSB4eHggbXMgc2hvdWxkIGJlDQo+ID4gZXhwbGFp bmVkDQo+ID4gPj4gZnVydGhlci4NCj4gPiA+Pg0KPiA+ID4+ICgzKSBIb3cgIklQdjYtb25seSBw cmVmZXJyZWQiIG1vZGUgaXMgc3VwcG9zZWQgdG8gYmUgc2V0IGF0IHRoZQ0KPiA+ID4+IGhvc3QN Cj4gPiBzaWRlOg0KPiA+ID4+DQo+ID4gPj4gPT0NCj4gPiA+PiAgIEEgREhDUCBjbGllbnQgU0hP VUxEIGFsbG93IGEgZGV2aWNlIGFkbWluaXN0cmF0b3IgdG8gY29uZmlndXJlDQo+ID4gPj4gICBJ UHY2LW9ubHkgcHJlZmVycmVkIG1vZGUgZWl0aGVyIGZvciBhIHNwZWNpZmljIGludGVyZmFjZSAo dG8NCj4gaW5kaWNhdGUNCj4gPiA+PiAgIHRoYXQgdGhlIGRldmljZSBpcyBJUHY2LW9ubHkgY2Fw YWJsZSBpZiBjb25uZWN0ZWQgdG8gYSBOQVQ2NCBuZXR3b3JrDQo+ID4gPj4gICB2aWEgdGhhdCBp bnRlcmZhY2UpIG9yIGZvciBhbGwgaW50ZXJmYWNlcy4NCj4gPiA+PiA9PQ0KPiA+ID4+DQo+ID4g Pj4gKiBJIGd1ZXNzIHRoZSBkZWZhdWx0IHZhbHVlIHdoZW4gdGhlIG9wdGlvbiBpcyBzdXBwb3J0 ZWQgYnkgYSBob3N0DQo+ID4gPj4gaXMgdG8gZGlzYWJsZSBpbmNsdWRpbmcgaXQgaW4gdGhlIHJl cXVlc3QuIFRoZSBkb2N1bWVudCBzaG91bGQNCj4gPiA+PiBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBv biB0aGUgZGVmYXVsdCBiZWhhdmlvci4NCj4gPiA+PiAqIElmIGFuIGV4cGxpY2l0IGFjdGlvbiBp cyBuZWVkZWQgZnJvbSB0aGUgdXNlciB0byBlbmFibGUgaW5jbHVkaW5nDQo+ID4gPj4gdGhlIG9w dGlvbiwgaGF2aW5nIGEgZGlzY3Vzc2lvbiB0byB3aGF0IGV4dGVudCB0aGUgZmVhdHVyZSBpcw0K PiA+ID4+IGxpa2VseSB0byBiZSBlbmFibGVkIHdvdWxkIGJlIG5lZWRlZC4NCj4gPiA+Pg0KPiA+ ID4+ICg0KSBUaGUgZG9jdW1lbnQgaXMgc3RpbGwgbWl4aW5nIHRoZSBESENQIGNsaWVudCB2cy4g aG9zdA0KPiA+ID4+IGJlaGF2aW9ycy4gRm9yIGV4YW1wbGUsDQo+ID4gPj4NCj4gPiA+PiAgIENs aWVudHMgbm90IGNhcGFibGUgb2Ygb3BlcmF0aW5nIGluIGFuIElQdjYtb25seSBOQVQ2NCBlbnZp cm9ubWVudA0KPiA+ID4+ICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eDQo+ID4gPj4gICBNVVNUIE5PVCBpbmNsdWRlIHRoZSBJUHY2LW9ubHkgUHJlZmVy cmVkIG9wdGlvbiBpbiB0aGUgUGFyYW1ldGVyDQo+ID4gPj4gICBSZXF1ZXN0IExpc3Qgb2YgYW55 IERIQ1AgcGFja2V0cyBhbmQgTVVTVCBpZ25vcmUgdGhhdCBvcHRpb24gaW4NCj4gPiA+PiAgIHBh Y2tldHMgcmVjZWl2ZWQgZnJvbSBESENQIHNlcnZlcnMuDQo+ID4gPj4NCj4gPiA+PiBkb2VzIG5v dCBtYWtlIHNlbnNlIGZvciBhIERIQ1AgY2xpZW50Lg0KPiA+ID4+DQo+ID4gPj4gQWxzbywgaG93 IHRoZSBob3N0IGlzIGFibGUgdG8gYXNzZXNzL2RldGVybWluZSB0aGF0IGl0IGlzIChub3QpDQo+ ID4gPj4gY2FwYWJsZQ0KPiA+IHRvDQo+ID4gPj4gYmVoYXZlIGluIHRoZSBJUHY2IG1vZGU/DQo+ ID4gPj4NCj4gPiA+PiAoNSkgVGhlIGRlZmluaXRpb24gb2YgSVB2NGFhUyBpcyBub3QgYWxpZ25l ZCB3aXRoIG90aGVyIFJGQ3M6IGUuZy4sDQo+ID4gUkZDODU4NQ0KPiA+ID4+IHNheXMgdGhlIGZv bGxvd2luZzoNCj4gPiA+Pg0KPiA+ID4+ICAgIklQdjRhYVMiIHN0YW5kcyBmb3IgIklQdjQtYXMt YS1TZXJ2aWNlIiwgbWVhbmluZyB0cmFuc2l0aW9uDQo+ID4gPj4gICB0ZWNobm9sb2dpZXMgZm9y IGRlbGl2ZXJpbmcgSVB2NCBpbiBJUHY2LW9ubHkgY29ubmVjdGl2aXR5Lg0KPiA+ID4+DQo+ID4g Pj4gV2hpbGUgeW91cnMgaXM6DQo+ID4gPj4NCj4gPiA+PiAgIElQdjQtYXMtYS1TZXJ2aWNlOiBh IGRlcGxveW1lbnQgc2NlbmFyaW8gd2hlbiBlbmQgaG9zdHMgYXJlIGV4cGVjdGVkDQo+ID4gPj4g ICB0byBvcGVyYXRlIGluIElQdjYtb25seSBtb2RlIGJ5IGRlZmF1bHQgYW5kIElQdjQgYWRkcmVz c2VzIGNhbiBiZQ0KPiA+ID4+ICAgYXNzaWduZWQgdG8gc29tZSBob3N0cyBpZiB0aG9zZSBob3N0 cyBleHBsaWNpdGx5IG9wdC1pbiB0byByZWNlaXZpbmcNCj4gPiA+PiAgIElQdjQgYWRkcmVzc2Vz Lg0KPiA+ID4+DQo+ID4gPj4gKDYpIERvIHlvdSBjb25zaWRlciBhIGhvc3Qgd2l0aCBDTEFUIGZ1 bmN0aW9uIGFzIGFuIElQdjYtb25seSBob3N0Pw0KPiA+ID4+DQo+ID4gPj4gSWYgc28sIHRoZSBm b2xsb3dpbmcgZGVmaW5pdGlvbiBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZlciB0byAiSVB2NA0K PiA+ID4+IGNvbm5lY3Rpdml0eSIgcmF0aGVyIHRoYW4gIklQdjQiIGluIGdlbmVyYWwuIFRoaXMg aXMgYmVjYXVzZSBhbg0KPiA+ID4+IElQdjQgYWRkcmVzcyBpcyByZXF1aXJlZCBmb3IgQ0xBVCBm b3IgZXhhbXBsZS4NCj4gPiA+Pg0KPiA+ID4+ID09DQo+ID4gPj4gICBJUHY2LW9ubHkgY2FwYWJs ZSBob3N0OiBhIGhvc3Qgd2hpY2ggZG9lcyBub3QgcmVxdWlyZSBJUHY0IGFuZCBjYW4NCj4gPiA+ PiAgIG9wZXJhdGUgb24gSVB2Ni1vbmx5IG5ldHdvcmtzLg0KPiA+ID4+ID09DQo+ID4gPj4NCj4g PiA+PiAoNykgV291bGRuJ3QgdGhlIGZvbGxvd2luZyBhZGQgYW4gZXh0cmEgZGVsYXkgZm9yIGFw cGxpY2F0aW9ucw0KPiA+ID4+IHJlcXVpcmluZyBDTEFUPw0KPiA+ID4+DQo+ID4gPj4gPT0NCj4g PiA+PiBUaGUgaG9zdCBNQVkgZGlzYWJsZSBJUHY0IHN0YWNrDQo+ID4gPj4gICBjb21wbGV0ZWx5 IGZvciBWNk9OTFlfV0FJVCBzZWNvbmRzIG9yIHVudGlsIHRoZSBuZXR3b3JrDQo+IGRpc2Nvbm5l Y3Rpb24NCj4gPiA+PiAgIGV2ZW50IGhhcHBlbnMuDQo+ID4gPj4gPT0NCj4gPiA+Pg0KPiA+ID4+ ICg4KSBDb25zaWRlciByZXR1cm5pbmcgYW4gYWRkcmVzcyBmcm9tIHRoZSByYW5nZSBkZWZpbmVk IGluIFJGQzczMzUNCj4gPiA+PiBmb3IgSVB2Ni1vbmx5IGhvc3RzLiBTdWNoIElQdjQgYWRkcmVz c2VzIGFyZSByZXF1aXJlZCBhbnl3YXkgZm9yDQo+ID4gPj4gc29tZSBJUHY2LQ0KPiA+IG9ubHkN Cj4gPiA+PiBob3N0cyAodGhvc2Ugd2l0aCBhIENMQVQgZm9yIGV4YW1wbGUpLg0KPiA+ID4+DQo+ ID4gPj4gPT09PQ0KPiA+ID4+ICAgVGhlIHJlc3VsdCBpcyB0aGF0IDE5Mi4wLjAuMC8yOSBtYXkg YmUgdXNlZCBpbiBhbnkgc3lzdGVtDQo+ID4gPj4gICB0aGF0IHJlcXVpcmVzIElQdjQgYWRkcmVz c2VzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggSVB2NA0KPiA+ID4+ICAgY29tbXVu aWNhdGlvbnMgaW4gYW4gSVB2Ni1vbmx5IG5ldHdvcmsgYnV0IGRvZXMgbm90IGVtaXQgSVB2NA0K PiBwYWNrZXRzDQo+ID4gPj4gICAib24gdGhlIHdpcmUiLg0KPiA+ID4+ID09PT0NCj4gPiA+Pg0K PiA+ID4+IENoZWVycywNCj4gPiA+PiBNZWQNCj4gPiA+Pg0KPiA+ID4+PiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gPiA+Pj4gRGUgOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmVuDQo+ID4gPj4+IExpbmtvdmEgRW52b3nDqSA6IG1h cmRpIDEwIGTDqWNlbWJyZSAyMDE5IDAxOjAyIMOAIDogZGhjd2dAaWV0Zi5vcmcNCj4gPiA+Pj4g Q2MgOiBWNiBPcHMgTGlzdCBPYmpldCA6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+ID4gPj4+IGRyYWZ0LWxpbmstZGhjLXY2b25seS0gMDEudHh0DQo+ID4gPj4+ DQo+ID4gPj4+IEhlbGxvLA0KPiA+ID4+Pg0KPiA+ID4+PiBUaGFua3MgdG8gZXZlcnlvbmUgZm9y IHZlcnkgcHJvZHVjdGl2ZSBjZW50aS10aHJlYWQgb24NCj4gPiA+Pj4gZHJhZnQtbGluay1kaGMt djZvbmx5LTAwIDspDQo+ID4gPj4+IEhlcmUgaXMgdGhlIGltcHJvdmVkIHZlcnNpb24sIC0wMS4N Cj4gPiA+Pj4NCj4gPiA+Pj4gVGhlIG1haW4gY2hhbmdlczoNCj4gPiA+Pj4NCj4gPiA+Pj4gLSBU aGUgb3B0aW9uIGlzIG5vdCB6ZXJvIGxlbmd0aCBhbnltb3JlLiBJdCBoYXMgNC1ieXRlcyB2YWx1 ZQ0KPiA+ID4+PiB3aGljaCBtaWdodCBjb250YWluIFY2T05MWV9XQUlUIHRpbWVyLiBCZW5lZml0 czoNCj4gPiA+Pj4gICAgLS0tIGFsbG93cyB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB0byBw aWxvdCB0aGUgY2hhbmdlcyBhbmQNCj4gPiA+Pj4gcm9sbGJhY2sgcXVpY2tseSBpZiBuZWVkZWQ7 DQo+ID4gPj4+ICAgIC0tLSBhZGRyZXNzZWQgc29tZSBjb25jZXJuIGFib3V0IGFuIG9wdGlvbiBo YXZpbmcgemVybyBsZW5ndGgNCj4gPiA+Pj4gKGFsbGVnZWRseSBpdCBtaWdodCBjb25mdXNlIHNv bWUgY2xpZW50cykNCj4gPiA+Pj4NCj4gPiA+Pj4gLSBVc2luZyBhIGRlZGljYXRlZCBhZGRyZXNz IHRvIHJldHVybiB0byBjbGllbnRzIGlzIG5vdyBhbg0KPiA+ID4+PiBvcHRpb25hbCBvcHRpbWlz YXRpb24uIEJ5IGRlZmF1bHQgdGhlIHNlcnZlciBpcyBleHBlY3RlZCBqdXN0IHRvDQo+ID4gPj4+ IHJldHVybiBhIHJhbmRvbSBhZGRyZXNzIChhcyB1c3VhbCkuDQo+ID4gPj4+DQo+ID4gPj4+IC0g VHlwb3MgZml4ZWQgKHByb2JhYmx5IHNvbWUgbmV3IHR5cG9zIGFkZGVkIHRob3VnaCkuDQo+ID4g Pj4+DQo+ID4gPj4+IFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdGhlIERIQyBXRyB0byBjb25zaWRl ciBhZG9wdGluZyB0aGlzIGRvY3VtZW50Lg0KPiA+ID4+Pg0KPiA+ID4+PiBUaGFuayB5b3UhDQo+ ID4gPj4+DQo+ID4gPj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQo+ ID4gPj4+IEZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ID4gPj4+IERhdGU6IFR1 ZSwgRGVjIDEwLCAyMDE5IGF0IDEwOjQ0IEFNDQo+ID4gPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGluay1kaGMtdjZvbmx5LTAxLnR4dA0KPiA+ID4+PiBU bzogVG9tZWsgTXJ1Z2Fsc2tpIDx0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbT4sIExvcmVuem8g Q29saXR0aQ0KPiA+ID4+PiA8bG9yZW56b0Bnb29nbGUuY29tPiwgSmVuIExpbmtvdmEgPGZ1cnJ5 QGdvb2dsZS5jb20+LCBNaWNoYWVsIEMuDQo+ID4gPj4+IFJpY2hhcmRzb24gPG1jcitpZXRmQHNh bmRlbG1hbi5jYT4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWxpbmstZGhjLXY2b25seS0wMS50eHQgaGFzIGJlZW4NCj4gPiA+ Pj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKZW4gTGlua292YSBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGDQo+ID4gPj4+IHJlcG9zaXRvcnkuDQo+ID4gPj4+DQo+ID4gPj4+IE5hbWU6ICAgICAg ICAgICBkcmFmdC1saW5rLWRoYy12Nm9ubHkNCj4gPiA+Pj4gUmV2aXNpb246ICAgICAgIDAxDQo+ ID4gPj4+IFRpdGxlOiAgICAgICAgICBJUHY2LU9ubHktUHJlZmVycmVkIE9wdGlvbiBmb3IgREhD UA0KPiA+ID4+PiBEb2N1bWVudCBkYXRlOiAgMjAxOS0xMi0wOQ0KPiA+ID4+PiBHcm91cDogICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gPj4+IFBhZ2VzOiAgICAgICAgICAxMA0K PiA+ID4+PiBVUkw6DQo+ID4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1saW5rLWRoYy12Nm9ubHktMDEudHh0DQo+ID4gPj4+IFN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saW5rLWRoYy0NCj4gdjZvbmx5 Lw0KPiA+ID4+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxpbmstZGhjLXY2b25seS0wMQ0KPiA+ID4+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1saW5rLWRoYy0NCj4gPiA+PiB2Nm9u bHkNCj4gPiA+Pj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1saW5rLWRoYy0NCj4gPiB2Nm9ubHktDQo+ID4gPj4gMDENCj4gPiA+Pj4NCj4g PiA+Pj4gQWJzdHJhY3Q6DQo+ID4gPj4+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBESENQ IG9wdGlvbiB0byBpbmRpY2F0ZSB0aGF0IGEgaG9zdA0KPiA+ID4+PiAgIHN1cHBvcnRzIGFuIElQ djYtb25seSBtb2RlIGFuZCB3aWxsaW5nIHRvIGZvcmdvIG9idGFpbmluZyBhbiBJUHY0DQo+ID4g Pj4+ICAgYWRkcmVzcyBpZiB0aGUgbmV0d29yayBwcm92aWRlcyBJUHY2IGNvbm5lY3Rpdml0eS4N Cj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4g PiA+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0DQo+ID4gPj4+IHRvb2xzLmlldGYub3JnLg0KPiA+ID4+Pg0KPiA+ID4+PiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiAtLQ0KPiA+ID4+ PiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo+ID4gPj4+DQo+ID4gPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4+IGRoY3dnIG1haWxp bmcgbGlzdA0KPiA+ID4+PiBkaGN3Z0BpZXRmLm9yZw0KPiA+ID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+IGRoY3dnIG1haWxpbmcg bGlzdA0KPiA+ID4+IGRoY3dnQGlldGYub3JnDQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From nobody Wed Dec 11 11:25:03 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DF120052 for ; Wed, 11 Dec 2019 11:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=kefk6s/L; dkim=pass (1024-bit key) header.d=juniper.net header.b=XYX6A+wH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OH1Lj3jNBUu for ; Wed, 11 Dec 2019 11:25:00 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3A5120058 for ; Wed, 11 Dec 2019 11:25:00 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBBJN1aJ028166 for ; Wed, 11 Dec 2019 11:24:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=N6XJlNVl2lMvKswJx2Xlm8aPViYJ4LSnYy+lHW7h+8I=; b=kefk6s/LEPYLgGiQmNhh80FMshZo/o4u/TUcVgd1mMQaOttXyghF88a+wNQyAW2fH/xC kix2DqPfuh8XnZBjTrZGQxXQ8bwrI+GNMpyeEk0Hd9ebzKSq6fzUEwgte88RFXNjeGEx EHMe+cq3v42IOexoyBLHBrACINxfaiw8PRPv+lAxtDHFZDh0dPeGc5vvNkQUasQoejSx XRpJWRgp0R5fQpw4qcEoqbWJhgiQRMxuzrhrFgNTcjJpUegzfl/SkD4FeTv94w41jVbZ +pEaAGtXlc5MRCVbF9PX9aqCQ/cTe2Lw5lKn8VmfS8oIaaensAEZ7CxLO8+IpUOB7VJ9 Xg== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by mx0b-00273201.pphosted.com with ESMTP id 2wu4a789m0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 11 Dec 2019 11:24:58 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2nFBN+nTndqasAwf4A0dVjrGd/FQTcnU0Q7yelljJ1xTqQbMy8ciUTRzsUVeWODPua7zCY67R8gcUZkPuxQTK852SroZCGI5NVz8RfgPGnvV8ZZKU8at+rjDBd5vb84CusI15h6yoGJ6SAJdZvnMXMAc7UIPWoxZAkCAGR+aJnVcPYmbVORm9uY8+HgbOEsPeL7HNSVgddJDobT4765jYeKTfe4RnFLVWeSIOMEel5vZe3jszTForcWpfUbTxR6UdzYKtcIA/IeiuFbUFk8dmjWNHutiFNBqi8YDeihGqS5/tme1KlS7aWhPhVcP4o/HYbEGAEw78xnYlsno0j7Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N6XJlNVl2lMvKswJx2Xlm8aPViYJ4LSnYy+lHW7h+8I=; b=Fb3lSAi7GxXbNBirqzzcXI/YGIt0R03ebWa9T7zNzQEhGhZfb8heSkOC06bLbCzg0Y2UOdWmu0YVOCklfMj+IsD2+hsFAjK7zzzk0fda95SQsazU9JtS2dazVapqMrIyzWKlgvGvXHvqlIMX1cSZt6VQcbziHmIAVaj+zX7b5S9Jjd9+9HxGRZY6fgJT0I33uS70TIJ97xVLOAEVarHxFSzRCn/7/P/7a8w/V8mZnCovcTOABDCKV0n5F90hpdNU5lo5lT7aioyN4A4tINfySwrTCe06r/9pBA/DO5nETgvTYWL/sRIOZRQlsdn/Vf0HbnhFUVpKryyd7RpGfIDhUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N6XJlNVl2lMvKswJx2Xlm8aPViYJ4LSnYy+lHW7h+8I=; b=XYX6A+wHQ/gzSz3t7V36/zqRqGhwIhV8nhPBpurMDLw3d5ntMlYiVEF0zXiZmqRfInEDH+L/FeycNmpf8FwFuLtCVQBM7GLhxKWYzBcbEVAoHjS40UlDBHmjzT3Cip+SC49pR2VSuRH64OKUmucESutUQfY5ZNzsiQYzRLu8ddA= Received: from BN7PR05MB5699.namprd05.prod.outlook.com (20.176.28.88) by BN7PR05MB4435.namprd05.prod.outlook.com (52.135.251.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.4; Wed, 11 Dec 2019 19:24:54 +0000 Received: from BN7PR05MB5699.namprd05.prod.outlook.com ([fe80::185e:d297:6499:4987]) by BN7PR05MB5699.namprd05.prod.outlook.com ([fe80::185e:d297:6499:4987%7]) with mapi id 15.20.2516.003; Wed, 11 Dec 2019 19:24:54 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** Thread-Index: AdWwWHiRWxQ+WRXLTVy31pEUMAbcDw== Content-Class: Date: Wed, 11 Dec 2019 19:24:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-12-11T19:24:53.1456759Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=86f30dc1-6994-4303-b328-b036a29bfb63; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b3c2aeba-5d17-4266-b431-08d77e6fcd44 x-ms-traffictypediagnostic: BN7PR05MB4435: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(498600001)(52536014)(66476007)(66946007)(66556008)(71200400001)(66446008)(64756008)(8676002)(186003)(7696005)(5660300002)(76116006)(33656002)(8936002)(9686003)(86362001)(4744005)(81166006)(81156014)(26005)(55016002)(6916009)(2906002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4435; H:BN7PR05MB5699.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BU29vXfNGdDtUJ0rn54z34GLwE55sXBzTneYGZnlsSQ8NRs5Sx/M5pejDhjL//Ijux3aZ6CA0aZYI9TQLWe7/ut0GJ/6l98kazNA7cIbXwwp8VUA71dJSdAOjL7vmg12JU8a4zM0Gd2x4ZNgzPwyXpVZekqI1Igp9UOF6gHyIhvH3CpsO+FlGz/j66gbgc1Oqc7kX1CPzanssNdFvKe3pzRsQkFVjnPmgu/iDK0z5w80sA5eKgnnPTl9XkvIIsQVhtWi05jHoGDIWcr3In1QF8ZZr9BH6TofHhvgl1eowOxGKciA0mD7SrpyWwQM0VDzp3BJ0vxHZ21OAJKg4kemLRUg6xExhZDLakmDZjyvb7CkQ3MnrRwVO9jMVjZw3Ez0uO+d65P2foiRkwZ8IoRRxuLK70ZrsDG6BocgvO699gCLYe22I9LtqYo7aEG5qJ0h x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0BN7PR05MB5699namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b3c2aeba-5d17-4266-b431-08d77e6fcd44 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 19:24:54.5096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: onlT34x1bZQzEETsmw0P+6Sz+CIA/dtC6nD55iP7GuWOdYLCY6bqJdKtaupaIeQjb6+WKqxcPW4b6maQfUPUUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4435 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_06:2019-12-11,2019-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 suspectscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=569 adultscore=0 mlxscore=0 spamscore=0 priorityscore=1501 phishscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912110159 Archived-At: Subject: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 19:25:02 -0000 --_000_BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0BN7PR05MB5699namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Each week between now and IETF 107, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-c= aches. When reviewing this draft, please indicate whether you think that V6OPS sho= uld adopt it a s a work item. Fred and Ron Juniper Business Use Only --_000_BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0BN7PR05MB5699namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Each week between now and IETF 107, we will revie= w and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-palet-= v6ops-464xlat-opt-cdn-caches.

 

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       Fred and Ron

 


Juniper Business= Use Only

--_000_BN7PR05MB5699BA200FB1CF3F05062EDAAE5A0BN7PR05MB5699namp_-- From nobody Thu Dec 19 19:52:32 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315BD12006F for ; Thu, 19 Dec 2019 19:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xgr_vlZJeTp for ; Thu, 19 Dec 2019 19:52:27 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB23120047 for ; Thu, 19 Dec 2019 19:52:27 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id k25so4243886pgt.7 for ; Thu, 19 Dec 2019 19:52:27 -0800 (PST) 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 :references:to; bh=VayWqwx7bIRjW2i8dHGmRm0uk8DK63+rCSNj+8Izkqs=; b=Hmki6IDrnGieRwNu8s7FWxvUXkuB88pRy+Xy5523jwJ2yIY7a5vzgcN8B3PRyyQ0Z8 J0k7abFphjGiOhVc768KV4d3U7ZAix77eRL/Otl5dL9lgeSoYWDZXcu+m78dD4gCpOeY TVJak8ZDRwQIihTrwEDFei0dEF00WEd3R2yScTqPlY0tjZS63eZNdKCJ+iP7dkj1cRnp zs9R79uS9pcr7lbXyWGladjF9UGdQGWWFIKSqNlmF2S2jNLcvU99utlmlqzTsnJ2dXeP 6eaFS10IZQyzgTqaQUPPKnnXcsYe8P5Z4FHVc1cHLaJSK5C/lZqIDlZjzZ3tbBCcC5d+ aNiQ== 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:references:to; bh=VayWqwx7bIRjW2i8dHGmRm0uk8DK63+rCSNj+8Izkqs=; b=QUBSY3W8Jbq6m+V1Jh9Q0i2w039ONEK0keFv4G2y2xlGDrtmF4DPTCK0vfENH2raqR 04ddiqHB6xGesqk/Z+kPPi+U282o1gAfcOrEGV4qew55z67natIv4NAVyZHdZD5tVnHl JCKIobLvwfCw6z6++WNPz0tJASPR9BrxBIPr5U0VxPoZPOVQ11sxIwvn8Jhm6s0Q1Cu9 OwEj2B4Tvmu/g/FCRZJW9uWWYq6txzwEI19egI+aj2ewmLqg0xHlpeafttiW6rG/gVEM QDjqZWKbO2CgkCF5f4yS6TwK+mvgIeZTgFvjuDfq6j5bchnzN+HnK7EtzB0and0R/o0F T3QQ== X-Gm-Message-State: APjAAAXy71L0BWahkInPwR3XXsNTRuV8e7lIITUr7x9dsTrMVBEQFk2h zoukgV6YiquicjljYsuIdxz2cpvV X-Google-Smtp-Source: APXvYqxSoAZZ54+4AwGQWIqPs7TycBt4yU6IVfLQxAR5q7rCThx9Ks+wG4JiHNhIdJeo+ZlpMr1uGg== X-Received: by 2002:a62:f243:: with SMTP id y3mr13928808pfl.146.1576813947008; Thu, 19 Dec 2019 19:52:27 -0800 (PST) Received: from ?IPv6:2600:8802:5900:13c4::102c? ([2600:8802:5900:13c4::102c]) by smtp.gmail.com with ESMTPSA id u5sm9760106pfm.115.2019.12.19.19.52.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2019 19:52:26 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E481E690-E322-430B-AFA9-7DEB750B82DE Content-Transfer-Encoding: 7bit From: Fred Baker Mime-Version: 1.0 (1.0) Date: Thu, 19 Dec 2019 19:52:25 -0800 Message-Id: <8422019A-6AA4-4D15-9A59-4F4D6C7A006A@gmail.com> References: <157679524983.15716.9860282906373154446.idtracker@ietfa.amsl.com> To: V6 Ops List X-Mailer: iPad Mail (17C5053a) Archived-At: Subject: [v6ops] Fwd: IETF 107 - Working Group/BOF/IRTF Scheduling X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 03:52:31 -0000 --Apple-Mail-E481E690-E322-430B-AFA9-7DEB750B82DE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will be asking for a slot for a working group meeting in Vancouver soon. T= he secretariat is asking for specific categories of conflict avoidance. If y= ou fall into any of these categories, please let Ron and I (v6ops-chairs@iet= f.org) know. Sent from my iPad Begin forwarded message: > From: IETF Agenda > Date: December 19, 2019 at 2:40:55 PM PST > To: Working Group Chairs > Subject: IETF 107 - Working Group/BOF/IRTF Scheduling > Reply-To: agenda@ietf.org >=20 > =EF=BB=BF-----------------------------------------------------------------= > IETF 107 =E2=80=93 Vancouver, Canada > Meeting Dates: March 21-27, 2020 > ----------------------------------------------------------------- >=20 > We are now accepting scheduling requests for all Working Groups, BOFs, and= Research Groups until Friday February 7, 2020. Please review the IETF 106 a= ttendance numbers below for your working group and adjust for IETF 107 as ne= cessary.=20 >=20 > As a reminder, the conflict list descriptions changed for IETF 106. These n= ew labels will continue for IETF 107. In an attempt to provide more clarity a= bout conflicts, the old priority options have been replaced with more explic= it indications about the type of conflict. These new options are: >=20 > - Chair Conflict: to indicate other WGs the Chairs also lead, or will be a= ctive participants in the upcoming meeting >=20 > - Technology Overlap: to indicate WGs with a related technology or a close= ly related charter >=20 > - Key Participant Conflict (e.g., presenter, Secretary, etc.): to indicate= WGs with which key participation may overlap in the upcoming meeting >=20 > The Special Request field will continue to be available for more specific n= eeds, and responsible AD Conflicts are already taken into consideration. Ple= ase make sure you take a few minutes to check your conflict lists carefully!= >=20 >=20 >=20 > The milestones and deadlines for scheduling-related activities are as foll= ows: > Cut-off dates are subject to change. >=20 > =E2=80=A2 2019-12-16 (Monday): Working Group and BOF scheduling begins. To= request a Working Group session, use the IETF Meeting Session Request Tool.= If you are working on a BoF request, it is highly recommended to tell the I= ESG now by sending an email to iesg@ietf.org to get advance help with the re= quest.=20 > =E2=80=A2 2020-02-07 (Friday): Cut-off date for requests to schedule Worki= ng Group meetings at UTC 23:59. To request a Working Group session, use the I= ETF Meeting Session Request Tool. > =E2=80=A2 2020-02-07 (Friday): Cut-off date for BOF proposal requests to A= rea Directors at UTC 23:59. To request a BOF, please see instructions on Req= uesting a BOF. > =E2=80=A2 2020-02-14 (Friday): Cut-off date for Area Directors to approve B= OFs at UTC 23:59. > =E2=80=A2 2020-02-21 (Friday): Preliminary agenda published for comment. > =E2=80=A2 2020-02-26 (Wednesday): Cut-off date for requests to reschedule W= orking Group and BOF meetings UTC 23:59. > =E2=80=A2 2020-02-28 (Friday): Final agenda to be published. > =E2=80=A2 2020-03-11 (Wednesday): Draft Working Group agendas due by UTC 2= 3:59; upload using IETF Meeting Materials Management Tool. > =E2=80=A2 2020-03-16 (Monday): Revised Working Group agendas due by UTC 23= :59; upload using IETF Meeting Materials Management Tool. >=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=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 > IETF 106 Meeting Attendance Numbers >=20 >=20 > 6lo - 39 > 6man - 121 > 6man 2nd session - 59 > 6tisch - 15 > abcd - 257 > ace - 40 > acme - 43 > alto - 15 > anima - 42 > anima 2nd session - 28=20 > avtcore - 16 > babel - 9 > bess - 74 > bess 2nd session - 59=20 > bfd - 17 > bier - 41 > bmwg - 22 > calext - 12 > cbor - 15 > ccamp - 35 > cfrg - 72 > coinrg - 74 > core - 25 > core - 22 > cose - 18 > detnet - 57 > detnet - 37 > dhc - 24 > dinrg - CANCELLED > dispatch - 70 > dmm - 46 > dnsop - 107 > dnsop 2nd session - 116=20 > dnssd - 69 > dnssd 2nd session - 30=20 > dots - 18 > dprive - 101 > dtn - 13 > emu - 38 > extra - 14 > gaia - 41 > gendispatch - 33 > git - 31 > grow - 34 > homenet - 29 > hrpc - 59 > httpbis - 75 > httpbis 2nd session - 41 > iccrg - 75 > icnrg - 65 > idr - 82 > idr 2nd session - 63 > intarea - 54 > ippm - 47 > ipsecme - 29 > irtfopen - 149 > jmap - 13 > lake - 62 > lamps - 28 > lisp - 25 > lpwan - 36 > lsr - 101 > lsr 2nd session - 40 > lsvr - 43 > lwig - 21 > manet - 13 > maprg - 92 > mathmesh - 92 > mboned - 17 > mls - 33 > mops - 41 > mpls - 86 > mptcp - 32 > netconf - 37 > netmod - 67 > netmod 2nd session - 54=20 > nmrg - 43 > nmrg 2nd session - 41 > ntp - 23 > nvo3 - 21 > nwcrg - 24 > oauth - 37 > oauth 2nd session - 34 > opsawg - 68 > panrg - 48 > pce - 42 > pearg - 87 > pim - 20 > qirg - 54 > quic - 158 > quic 2nd session - 94 > rats - 36 > rats 2nd session - 37 > raw - 114 > regext - 38 > rift - 25 > rmcat - 17 > roll - 19 > roll 2nd session - 24=20 > rseme - 62 > rtgwg - 129 > rtgwg 2nd session - 78 > rum - 6 > saag - 74 > sacm - 20 > secdispatch - 82 > sidrops - 62 > spring - 188 > spring 2nd session - 67=20 > stir - 24 > suit - 52 > t2trg - 54 > taps - 37 > tcpm - 36 > teas - 63 > teas 2nd session - 81=20 > teep - 44 > teep 2nd session - 31=20 > tls - 85 > tls 2nd session - 75 > tmrid - 45 > tsvarea - 50 > tsvwg - 98 > tsvwg 2nd session - 90=20 > txauth - 91 > v6ops - 64 > webtrans - 129 > wpack - 91 >=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=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 > How to Request a WG Session or BOF: >=20 > Requests to schedule Working Group sessions should be submitted using the "= IETF Meeting Session Request Tool." The URL for the tool is: >=20 > https://datatracker.ietf.org/secr/sreq/ >=20 > If you require an account on this tool, or assistance in using it, then pl= ease send a message to ietf-action@ietf.org. If you are unable to use the t= ool, then you may send your request via e-mail to agenda@ietf.org, with a co= py to the appropriate Area Director(s). >=20 > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a c= opy to the appropriate Area Director(s). >=20 > When submitting a BOF session request by e-mail, please include the BOF ac= ronym in the Subject line. >=20 > BOFs will NOT be scheduled unless the Area Director approves the BOF. The p= roponents behind a BOF need to contact a relevant Area Director, preferably w= ell in advance of the BOF approval deadline date. The AD needs to have the f= ull name of the BOF, its acronym, suggested names of chairs, an agenda, full= description of the BOF and the information covered in item 3. Please read R= FC 5434 for instructions on how to drive a successful BOF effort.=20 >=20 >=20 > You MUST provide the following information before a BOF session will be sc= heduled: >=20 > a. BOF full name with acronym in brackets:=20 > b. AREA under which the BOF appears: > c. CONFLICTS you wish to avoid, please be as specific as possible: > d. Expected Attendance: > e. Special requests: > f. Number of sessions: > g. Length of session: 1 hour, 1.5 hours, 2 hours > =20 > For more information on scheduling Working Group and BOF sessions, please r= efer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (h= ttp://www.ietf.org/rfc/rfc2418.txt). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Submitting Session Agendas >=20 > Please submit the agendas for your Working Group sessions as early as poss= ible using the "IETF Meeting Materials Management Tool," a Web-based tool fo= r making your meeting agenda, minutes, and presentation slides available to t= he community before, during, and after an IETF meeting. If you are a BOF ch= air, then you may use the tool to submit a revised agenda as well as other m= aterials for your BOF once the BOF has been approved. >=20 > The URL for the tool is: >=20 > https://datatracker.ietf.org/secr/proceedings/ >=20 > Agendas submitted via the tool will be available to the public on the "IET= F Meeting Materials" webpage as soon as they are submitted. >=20 > The URL for the "IETF 107 Meeting Materials" Web page is: >=20 > https://datatracker.ietf.org/meeting/107/materials.html >=20 > If you are a Working Group chair, then you already have accounts on the "I= ETF Meeting Session Request Tool" and the "IETF Meeting Materials Management= Tool." The same User ID and password will work for both tools. If you are= a BOF chair who is not also a Working Group chair, then you will be given a= n account on the "IETF Meeting Materials Management Tool" when your BOF has b= een approved. If you require assistance in using either tool, or wish to re= port a bug, then please send a message to: ietf-action@ietf.org. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > For your convenience please find a list of the IETF Area Directors with th= eir e-mail addresses below: >=20 >=20 > IETF Chair > Alissa Cooper >=20 >=20 > Applications and Real-Time Area (art) > Barry Leiba > Alexey Melnikov > Adam Roach >=20 >=20 >=20 > Internet Area (int) > Suresh Krishnan > =C3=89ric Vyncke >=20 >=20 >=20 > Operations & Management Area (ops) > Ignas Bagdonas > Warren Kumari >=20 >=20 >=20 > Routing Area (rtg) > Deborah Brungard > Alvaro Retana > Martin Vigoureux >=20 >=20 >=20 > Security Area (sec)=20 > Roman Danyliw > Benjamin Kaduk >=20 >=20 >=20 > Transport Area (tsv) > Mirja K=C3=BChlewind > Magnus Westerlund >=20 --Apple-Mail-E481E690-E322-430B-AFA9-7DEB750B82DE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I will be asking for a slot for a working g= roup meeting in Vancouver soon. The secretariat is asking for specific categ= ories of conflict avoidance. If you fall into any of these categories, pleas= e let Ron and I (v6ops-chairs@ietf.org) know.

Sent f= rom my iPad

Begin forwarded message:

=
From: IETF Agenda <agen= da@ietf.org>
Date: December 19, 2019 at 2:40:55 PM PST
To= : Working Group Chairs <wgchairs@ietf.org>
Subject: I= ETF 107 - Working Group/BOF/IRTF Scheduling
Reply-To: agenda@i= etf.org

=EF=BB=BF------------------------------------------------------------= -----
IETF 107 =E2=80=93 Vancouver, Canada
M= eeting Dates: March 21-27, 2020
----------------------------= -------------------------------------

We ar= e now accepting scheduling requests for all Working Groups, BOFs, and Resear= ch Groups until Friday February 7, 2020. Please review the IETF 106 attendan= ce numbers below for your working group and adjust for IETF 107 as necessary= .

As a reminder, the conflict list descrip= tions changed for IETF 106. These new labels will continue for IETF 107. In a= n attempt to provide more clarity about conflicts, the old priority options h= ave been replaced with more explicit indications about the type of conflict.= These new options are:

- Chair Conflict: t= o indicate other WGs the Chairs also lead, or will be active participants in= the upcoming meeting

- Technology Overlap:= to indicate WGs with a related technology or a closely related charter

- Key Participant Conflict (e.g., presenter, Se= cretary, etc.): to indicate WGs with which key participation may overlap in t= he upcoming meeting

The Special Request fie= ld will continue to be available for more specific needs, and responsible AD= Conflicts are already taken into consideration. Please make sure you take a= few minutes to check your conflict lists carefully!
=


The milestones and deadlines for= scheduling-related activities are as follows:
Cut-off dates= are subject to change.

=E2=80=A2 2019-12-1= 6 (Monday): Working Group and BOF scheduling begins. To request a Working Gr= oup session, use the IETF Meeting Session Request Tool. If you are working o= n a BoF request, it is highly recommended to tell the IESG now by sending an= email to iesg@ietf.org to get advance help with the request.
=E2=80=A2 2020-02-07 (Friday): Cut-off date for requests to schedule Work= ing Group meetings at UTC 23:59. To request a Working Group session, use the= IETF Meeting Session Request Tool.
=E2=80=A2 2020-02-07 (Fri= day): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.= To request a BOF, please see instructions on Requesting a BOF.
=E2=80=A2 2020-02-14 (Friday): Cut-off date for Area Directors to approv= e BOFs at UTC 23:59.
=E2=80=A2 2020-02-21 (Friday): Prelimin= ary agenda published for comment.
=E2=80=A2 2020-02-26 (Wedn= esday): Cut-off date for requests to reschedule Working Group and BOF meetin= gs UTC 23:59.
=E2=80=A2 2020-02-28 (Friday): Final agenda to= be published.
=E2=80=A2 2020-03-11 (Wednesday): Draft Worki= ng Group agendas due by UTC 23:59; upload using IETF Meeting Materials Manag= ement Tool.
=E2=80=A2 2020-03-16 (Monday): Revised Working G= roup agendas due by UTC 23:59; upload using IETF Meeting Materials Managemen= t Tool.


=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D


IETF 106 Meeting Atten= dance Numbers


6lo - 39
6man - 121
6man 2nd session - 59
6tisch - 15
abcd - 257
ace - 40
= acme - 43
alto - 15
anima - 42<= br>anima 2nd session - 28
avtcore - 16
babel - 9
bess - 74
bess 2nd session - 59 <= /span>
bfd - 17
bier - 41
bmwg - 22=
calext - 12
cbor - 15
ccamp= - 35
cfrg - 72
coinrg - 74
= core - 25
core - 22
cose - 18
detnet - 57
detnet - 37
dhc - 24dinrg - CANCELLED
dispatch - 70
dmm -= 46
dnsop - 107
dnsop 2nd session - 116
dnssd - 69
dnssd 2nd session - 30
dots - 18
dprive - 101
dtn - 13emu - 38
extra - 14
gaia - 41=
gendispatch - 33
git - 31
grow - 3= 4
homenet - 29
hrpc - 59
htt= pbis - 75
httpbis 2nd session - 41
iccrg - 7= 5
icnrg - 65
idr - 82
idr 2n= d session - 63
intarea - 54
ippm - 47=
ipsecme - 29
irtfopen - 149
jmap -= 13
lake - 62
lamps - 28
lis= p - 25
lpwan - 36
lsr - 101
= lsr 2nd session - 40
lsvr - 43
lwig - 21
manet - 13
maprg - 92
mathmesh -= 92
mboned - 17
mls - 33
mop= s - 41
mpls - 86
mptcp - 32
= netconf - 37
netmod - 67
netmod 2nd session -= 54
nmrg - 43
nmrg 2nd session - 41<= br>ntp - 23
nvo3 - 21
nwcrg - 24
oauth - 37
oauth 2nd session - 34
opsawg - 68
panrg - 48
pce - 42
<= span>pearg - 87
pim - 20
qirg - 54quic - 158
quic 2nd session - 94
rats= - 36
rats 2nd session - 37
raw - 114=
regext - 38
rift - 25
rmcat - 17
roll - 19
roll 2nd session - 24
rseme - 62
rtgwg - 129
rtgwg 2nd session= - 78
rum - 6
saag - 74
sacm= - 20
secdispatch - 82
sidrops - 62spring - 188
spring 2nd session - 67
stir - 24
suit - 52
t2trg - 54
<= span>taps - 37
tcpm - 36
teas - 63teas 2nd session - 81
teep - 44
teep= 2nd session - 31
tls - 85
tls 2nd session -= 75
tmrid - 45
tsvarea - 50
= tsvwg - 98
tsvwg 2nd session - 90
txauth - 9= 1
v6ops - 64
webtrans - 129
= wpack - 91


=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D


How to Request a WG= Session or BOF:

Requests to schedule Worki= ng Group sessions should be submitted using the "IETF Meeting Session Reques= t Tool." The URL for the tool is:

https://d= atatracker.ietf.org/secr/sreq/

If you requi= re an account on this tool, or assistance in using it, then please send a me= ssage to ietf-action@ietf.org.  If you are unable to use the tool, then= you may send your request via e-mail to agenda@ietf.org, with a copy to the= appropriate Area Director(s).

Requests to s= chedule BOF sessions must be sent to agenda@ietf.org with a copy to the appr= opriate Area Director(s).

When submitting a= BOF session request by e-mail, please include the BOF acronym in the Subjec= t line.

BOFs will NOT be scheduled unless t= he Area Director approves the BOF. The proponents behind a BOF need to conta= ct a relevant Area Director, preferably well in advance of the BOF approval d= eadline date. The AD needs to have the full name of the BOF, its acronym, su= ggested names of chairs, an agenda, full description of the BOF and the info= rmation covered in item 3. Please read RFC 5434 for instructions on how to d= rive a successful BOF effort.


<= span>You MUST provide the following information before a BOF session will be= scheduled:

a. BOF full name with acronym i= n brackets:
b. AREA under which the BOF appears:
= c. CONFLICTS you wish to avoid, please be as specific as possible:
d. Expected Attendance:
e. Special requests:
f. Number of sessions:
g. Length of session: 1= hour, 1.5 hours, 2 hours
     &nb= sp;        
For more information on sche= duling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "I= ETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc241= 8.txt).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

Submitting Session Agendas
=
Please submit the agendas for your Working Group sessions a= s early as possible using the "IETF Meeting Materials Management Tool," a We= b-based tool for making your meeting agenda, minutes, and presentation slide= s available to the community before, during, and after an IETF meeting. &nbs= p;If you are a BOF chair, then you may use the tool to submit a revised agen= da as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/secr/proceedings/

Agendas submitted via the tool will be available to the pu= blic on the "IETF Meeting Materials" webpage as soon as they are submitted.<= /span>

The URL for the "IETF 107 Meeting Materials= " Web page is:

https://datatracker.ietf.org= /meeting/107/materials.html

If you are a Wo= rking Group chair, then you already have accounts on the "IETF Meeting Sessi= on Request Tool" and the "IETF Meeting Materials Management Tool."  The= same User ID and password will work for both tools.  If you are a BOF c= hair who is not also a Working Group chair, then you will be given an accoun= t on the "IETF Meeting Materials Management Tool" when your BOF has been app= roved.  If you require assistance in using either tool, or wish to repo= rt a bug, then please send a message to: ietf-action@ietf.org.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For your convenience please find a list of the IETF Area Directo= rs with their e-mail addresses below:


IETF Chair
Alissa Cooper <alissa@cooperw.in&g= t;


Applications and Real-T= ime Area (art)
Barry Leiba <barryleiba@computer.org>
Alexey Melnikov <aamelnikov@fastmail.fm>
Adam Roach <adam@nostrum.com>



Internet Area (int)
Suresh Kris= hnan <suresh@kaloom.com>
=C3=89ric Vyncke <evyncke@= cisco.com>



<= span>Operations & Management Area (ops)
Ignas Bagdonas &= lt;ibagdona@gmail.com>
Warren Kumari <warren@kumari.ne= t>



Rou= ting Area (rtg)
Deborah Brungard <dbrungard@att.com>
Alvaro Retana <aretana@cisco.com>
Marti= n Vigoureux <martin.vigoureux@nokia.com>



Security Area (sec)
R= oman Danyliw <rdd@cert.org>
Benjamin Kaduk <kaduk@m= it.edu>



Transport Area (tsv)
Mirja K=C3=BChlewind <ietf@kuehlew= ind.net>
Magnus Westerlund <magnus.westerlund@ericsson= .com>

= --Apple-Mail-E481E690-E322-430B-AFA9-7DEB750B82DE-- From fhfrediani@gmail.com Fri Dec 20 15:21:42 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3439C1208C8 for ; Fri, 20 Dec 2019 15:21:42 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz7w6lwCDwAM for ; Fri, 20 Dec 2019 15:21:39 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABE31208DC for ; Fri, 20 Dec 2019 15:21:39 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id x17so4753977pln.1 for ; Fri, 20 Dec 2019 15:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=EHd19jdk4lADdqrgxMeKVnoh/H1qcELrAs+YRWsR9OY=; b=Fj61uykpZc7xRHEwcM+NyudBuS5Lrmj3pScwQdm5H27LGIWwl5dzVJtd7ns0Tkal6d 4U8YiIjz1I6qHF5+AqhMKE8kxyCye8Ep6sp7OUa4fJ6AmoxaPR/jBy3DTBYomKrJ+nQk IEtQdNpdl57hA/5V20W1gG9Y7TlCVl0dvhOlYTmjjDws3vM/sXHtuf9mfYxWqWeZD8ap QbRzvjAftfpJjCWWq0HUKWmuwhi4BbXhLIhPSwSoxTPgoSpeNZz42riOXyXVCM4x6zot ++ErpQJm4SJeCMtabCAsIsysDn7NkEBvBA18epbKQxKlE0SOCOhOK2jX0TaRl+3EA6Fp mXbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EHd19jdk4lADdqrgxMeKVnoh/H1qcELrAs+YRWsR9OY=; b=ogK3gWBsS2DkejmsgjfB+dUyE8heEkuvUwVsIjCeR3Re/OE1A1SWASbtdcIQprWPyh 6+JlFZ459Pr7zXQ6O5sSsD6ULs8QHT4g4k3YMHKkzzU9vB++bk0+cYutBKHJ8ulykEFl KNuGTNVXqXo0SgobPDaAV2BY0VVvPanNkudZb5B9bPshvNxUUnvzl8++dxDYAykGQn95 QlwFycaDSsqTZIFail1YqHMVhikg3tZU7JJ817BOiLE6PGc7bHTQJJbbDN5Mjg4eAdNg ZN2SCBWkIqilsyf91SD3c/gDK6azQxnWKkVxk0TfetxGuZGm0RJFGM5bCVateBgfrIP2 WkKw== X-Gm-Message-State: APjAAAV0CPnlW4+bIj9CVRr7LmWrMiFlpWfuRrCevk2ZeLM/bnz+HRqj x0G5HZ92qMCRIdjzXo/hYEGHbGuH X-Google-Smtp-Source: APXvYqx48hOEBMIO8Vuw+VL6IFcD+7uDHD3ooTgLdcvEf/c1drAsKHt458lUvEPVmuYuRYebkvoLxA== X-Received: by 2002:a17:902:ba97:: with SMTP id k23mr17761767pls.343.1576884098800; Fri, 20 Dec 2019 15:21:38 -0800 (PST) Received: from ?IPv6:2804:368:9:33e0::1? ([2804:368:9:33e0::1]) by smtp.gmail.com with ESMTPSA id c199sm14658216pfb.126.2019.12.20.15.21.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Dec 2019 15:21:38 -0800 (PST) References: <660506608.216541286.1576808712102.JavaMail.zimbra@telecentro.net.ar> From: Fernando Frediani To: v6ops@ietf.org Message-ID: <59162d1f-a211-4bb9-47ad-730a3e130993@gmail.com> Date: Fri, 20 Dec 2019 20:21:37 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <660506608.216541286.1576808712102.JavaMail.zimbra@telecentro.net.ar> Content-Type: multipart/alternative; boundary="------------760FF50DD886241A9ABB48AB" Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 00:21:03 -0000 This is a multi-part message in MIME format. --------------760FF50DD886241A9ABB48AB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello After reviewing the updated draft version I wish to show my support to it for v6ops to adopt it as a work item. I am a believer of 464XLAT as a transition mechanism for long term, have been conducting controlled usage and one of the issues I was able to spot is exactly of those IPv4-only devices where external traffic will be kept in IPv4. If this works advances and works as proposed it has the potential to convert a lot of IPv4-only traffic into IPv6 traffic or at least to avoid the traffic passing trough the PLAT equipment unnecessarily. Best regards Fernando Frediani > ------------------------------------------------------------------------ > *De: *"Ron Bonica" > *Para: *"v6ops@ietf.org list" > *Enviados: *Miércoles, 11 de Diciembre 2019 16:24:54 > *Asunto: *[v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for > Adoption** > > Folks, > > Each week between now and IETF 107, we will review and discuss one > draft with an eye towards progressing it. > > This week, please review and comment on > draft-palet-v6ops-464xlat-opt-cdn-caches. > > When reviewing this draft, please indicate whether you think that > V6OPS should adopt it a s a work item. > > Fred and Ron > > > Juniper Business Use Only > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > LACNOG mailing list > LACNOG@lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog --------------760FF50DD886241A9ABB48AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello

After reviewing the updated draft version I wish to show my support to it for v6ops to adopt it as a work item.

I am a believer of 464XLAT as a transition mechanism for long term, have been conducting controlled usage and one of the issues I was able to spot is exactly of those IPv4-only devices where external traffic will be kept in IPv4. If this works advances and works as proposed it has the potential to convert a lot of IPv4-only traffic into IPv6 traffic or at least to avoid the traffic passing trough the PLAT equipment unnecessarily.

Best regards
Fernando Frediani


De: "Ron Bonica" <rbonica=40juniper.net@dmarc.ietf.org>
Para: "v6ops@ietf.org list" <v6ops@ietf.org>
Enviados: Miércoles, 11 de Diciembre 2019 16:24:54
Asunto: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption**

Folks,

 

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

 

This week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-caches.

 

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.

 

                                                      Fred and Ron

 


Juniper Business Use Only


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

_______________________________________________
LACNOG mailing list
LACNOG@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
--------------760FF50DD886241A9ABB48AB-- From nobody Sat Dec 21 02:37:34 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC8120A3D for ; Sat, 21 Dec 2019 02:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 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, MALFORMED_FREEMAIL=1.601, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY572w5Fydor for ; Sat, 21 Dec 2019 02:37:32 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F419F120A32 for ; Sat, 21 Dec 2019 02:37:31 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id c129so3275814vkh.7 for ; Sat, 21 Dec 2019 02:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=JJYyPN9Ndp0+gmeUHSXY+HvSDrtsPAQpxtd31CzS8jk=; b=AhTdyX838NhdFpx+WdIn3lIjdfvLsPiI3M+m5P3Ujd4pSNlDwvTYigp5o/ZyEsAP2W f4okI0Hc2BwZ/qsa2R6xwmntG2D78JoJLgM6c2w31Ga2DuY7oWL5lkP8TIJaO6OExm2t xby/U+RzXsFdap1RAlPsNsb8QFBb6gYrD62uhqqGJ3VlDnveS6eQGANfQYgmd8wNYZjy DAonnjRBU8/GgK53lsvVDeyC0XZQpHqlCKggUr4m+kIHtns+s6gR6sH6ukdB6R3qkMcQ PjsGpztj7Ogxis+PW+tvy6OutN1AmgLUNzc+vgP4PLZCVE9F1p7XTrjs2icHoVtnWun/ zV8g== 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:cc; bh=JJYyPN9Ndp0+gmeUHSXY+HvSDrtsPAQpxtd31CzS8jk=; b=a/OS/dKM75v2rRQrm05lO614TzW9BQmAC3NlVGzOf9dMRxXbSKL0Mplm1+oamRk2S9 H2bpf0XlngBjjNoGoE2twPjcFx6DgR7ns//CqrPr+zKviVT0YH4wrNt9gmJSTjbiDL6J HstWUYTP3TEdaqv90qQ+Y9gOfaJvqMYwqbfJilBXXH9wB7098k0RnyzlmZIBvIHgWAsR azl9+HiSnWxgrZrLhsFGUT5aH2E32hJZ+4Bssctj9zq4lJE97O/xIBv98cY+zY3HjaM6 cyvk+hBwWNBZqPL4YBTCXccZJ98lLKTcWj4gwP/BlEWuHF2aGjNQFSkTk6bxt0h2ulFZ 3dig== X-Gm-Message-State: APjAAAV9sAuKuK5LOOGiFKkBLEY1+Pmtp/vE26dO8OBrxnW3aL8JzSS/ JwkBxRkB0V++ZzKsNExqwPvEtpxKMtRN+JLzs1/GbsF5ha0= X-Google-Smtp-Source: APXvYqzZXRvvCTfbnTfJcc2Q6wWoCgTq17AiO1PgBeRLERUJ8mR1w48wRfw3wiXKrWAG7IsmCsdlQaHgt1YObwfZW9A= X-Received: by 2002:a1f:4354:: with SMTP id q81mr12856003vka.31.1576924650757; Sat, 21 Dec 2019 02:37:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Uesley Correa Date: Sat, 21 Dec 2019 07:37:15 -0300 Message-ID: Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a56262059a3461b0" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches **Call for Adoption** X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 10:37:33 -0000 --000000000000a56262059a3461b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all. I reviewed the draft and show my support for adopt this draft as a work. I'm testing a 464XLAT in a ISP scenery for tests and I think why this work is a helpful for a massive IPv6 adoption. Regards, Uesley Corr=C3=AAa - Analista de Telecomunica=C3=A7=C3=B5es CEO Telecom Consultoria, Entrenamiento y Servicios CEO Telecom Fiber Solutions Em qua., 11 de dez. de 2019 =C3=A0s 16:25, Ron Bonica escreveu: > Folks, > > > > Each week between now and IETF 107, we will review and discuss one draft > with an eye towards progressing it. > > > > This week, please review and comment on > draft-palet-v6ops-464xlat-opt-cdn-caches. > > > > When reviewing this draft, please indicate whether you think that V6OPS > should adopt it a s a work item. > > > > Fred and Ron > > > > Juniper Business Use Only > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000a56262059a3461b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all.

I reviewed the draft and show my support= for adopt this draft as a work. I'm testing a 464XLAT in a ISP scenery= =C2=A0for tests and I think why this work is a helpful for a massive IPv6 a= doption.

Regards,

=
Uesley Corr=C3=AAa - Analista de Te= lecomunica=C3=A7=C3=B5es
CEO Telecom Consultoria, Ent= renamiento y Servicios
CEO Telecom Fiber Solutions


Em= qua., 11 de dez. de 2019 =C3=A0s 16:25, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org&g= t; escreveu:

Folks,

=C2=A0

Each week between now and IETF 107, we will review and discuss one draft= with an eye towards progressing it.

=C2=A0

This week, please review and comment on draft-palet-= v6ops-464xlat-opt-cdn-caches.

=C2=A0

When reviewing this draft, please indicate whether y= ou think that V6OPS should adopt it a s a work item.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fred and Ron

=C2=A0


Juniper Business Use Only

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000a56262059a3461b0-- From nobody Sat Dec 21 08:30:07 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13F3120020; Sat, 21 Dec 2019 08:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CoMFSo/Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gq3+O9RI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQp0cbOBmr4R; Sat, 21 Dec 2019 08:29:59 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C693120018; Sat, 21 Dec 2019 08:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=642; q=dns/txt; s=iport; t=1576945799; x=1578155399; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lF/0qc+bhhcq0+CY/zIVsi/wBfyAQOboHNPlxFOoXug=; b=CoMFSo/Z4tQTwwgCbIIQ/wydrd8SoYFyk76QIlDCbNgbW+Yh5io/BdGs wOuRVklw/SONcTWTJ2x4y+l5ZWNGXUDICluIRlap9U7t4pM7WsDEPBXe9 85pReAfkwy117uty1saeDW4cyGDIzFgwvnbyt8Gtti0eI2hHxOiideTAB A=; IronPort-PHdr: =?us-ascii?q?9a23=3A+pq9/RMyDNkWOb7nxocl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPCQAESP5d/5BdJa1lHgELHINJUAW?= =?us-ascii?q?BRCAECyqEB4NGA4p2mmeBQoEQA1QJAQEBDAEBLQIBAYRAGYIFJDgTAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FNwyFYRYREQwBASwLAREBIgImAgQwFRIEAQ0FIoMAgkcDLgG?= =?us-ascii?q?hCgKBOIhhdYEygn4BAQWCSoJFGIIMCYEOKIwZGoFBP4E4IIcXg0wyggoikDq?= =?us-ascii?q?eWgqCNJYZG4I2mCGOUppWAgQCBAUCDgEBBYFpIoFYcBU7KgGCQVAYDY0Sg3O?= =?us-ascii?q?KU3SBKJIDAQE?= X-IronPort-AV: E=Sophos;i="5.69,340,1571702400"; d="scan'208";a="691938870" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Dec 2019 16:29:57 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id xBLGTvRi013322 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 21 Dec 2019 16:29:57 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 10:29:56 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 10:29:56 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 21 Dec 2019 11:29:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N3R5XYvhqMOaQDZeXqpZWO25ZXL4sIWT2bAwbdIl9/RSc+PQag8uEXtnt/vC2XF6qNtu/0sjqKUVbEHauxFSfQGTAfkzGvyO7rakQamhzgNhL9HAtoefUQwznV9z/YXWBCKvgi7NHJZLl66sd/Sk+tJqxtEIWwxnQF/LUXPlugqxfBCGImqtbAVvwDYncVGRqmX/T9p+HBYeAaI/o57ssbb9XnzW0o/UyLbd0wXBEZXyrzEodVGLOowSi19BTp+Pq3FdercpC/NhjIWhS9CzfNX6Z+/ZZycqZMMWZcfT6KKUdV4sxMwSKhzrII4Mwm6qUe7evV7gHvTg0anFd2HAyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lF/0qc+bhhcq0+CY/zIVsi/wBfyAQOboHNPlxFOoXug=; b=CJqyUjuZTa2ZH+93Wsly4nrhpTSjFzbhjHkUYl0oRUjJWEYWlPlyewZB+jqyV4el2xJ3SvlS69bPV9KQaYWfrQR21vAO5jmytStZ3Y1/gwwtyZDq9ZViJg1OzJ4hvM40RyoQWtVp2W6VGzUBOOO+7ndwo47cZu93LDAndTne7tyFCk9UASfoq2DJF0zFsxeTCmWXMOW3Jn4AFgKo+IJjVaY/xayxsuGYlu0N3TWIyg1o+j9F8+a6kTGqTPnSNi5Z6pM1scFPN900ZkMWaMcD7479DaheuC+m5IZld+vMFeWXFLuIxjpIOhK3xGE98w4CFzN0Ln3deXtdIrNOWak2rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lF/0qc+bhhcq0+CY/zIVsi/wBfyAQOboHNPlxFOoXug=; b=gq3+O9RIqEzBaG0+Tc6Inicynw8zqQd1rbFC83ud0ZaA4CKaLgIoNhd+pg+a1NYZui30PfunwTd3wt095SHCghOKwhe9sHlZZiF1DNGUG8ynzOv1sX8nGxmktJEjNZYTsRmq0Er54WyuV7X4/ftu7g47WSzbr7o9CbiLeW2HJuk= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1931.namprd11.prod.outlook.com (10.175.88.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.17; Sat, 21 Dec 2019 16:29:55 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::f8ba:7d8d:391d:4302]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::f8ba:7d8d:391d:4302%12]) with mapi id 15.20.2559.012; Sat, 21 Dec 2019 16:29:55 +0000 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" , 6man WG , "atn@ietf.org" CC: "6man-chairs@ietf.org" <6man-chairs@ietf.org> Thread-Topic: Let's use 6MAN + ATN for the documents about IPv6 for the plane industry Thread-Index: AQHVuBvgE3TSVZoa2EKKHKU/wIQfKw== Date: Sat, 21 Dec 2019 16:29:55 +0000 Message-ID: <5DCD8F6A-1D0D-454D-92F2-2A9DC026F89C@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:d881:4c0f:21ca:b59a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b098f22e-3256-4076-1bf7-08d786330361 x-ms-traffictypediagnostic: DM5PR11MB1931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(39860400002)(136003)(189003)(199004)(71200400001)(478600001)(91956017)(316002)(110136005)(4744005)(66946007)(66446008)(64756008)(76116006)(66556008)(66476007)(6486002)(450100002)(5660300002)(2616005)(33656002)(4326008)(86362001)(186003)(8676002)(81166006)(81156014)(6512007)(8936002)(36756003)(6506007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1931; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8JIamHfua9811QqnAhbmohy03VuI9uFDEGPNYrSj/akSnLzRRJUxtWouKeJCflNvUQQkC/JPA+WAc81Ujl66guDzIaLxQOHsmpcL8HIAbe4yppnASYivkoZnw7/+84zRcRxnlXroJqnZONOvbwwoFYbDUw4/oaHBCXj8159a1Qgv42ZbZtcnbdcqYcVdnX1pbusZ8ctnOj9E50/d42B4AWiP7JhH2zzqswVgG3uC5FsZe8fPxkwrmy/R3o/5OtD5+H9c1IlYiRDpREETOeyp9asnNw4JmavebyJZkUxUcQSXNDESNwkQ4CIp5w1TJR313EZBfD9EQZ4qqbs37e6h8EK5TvUzGhQhe+TBi8/glHSZkaf9Q56zyQJRKLXoKzD1tGhe1r1lKESlaw6/QZnrzT1XEFP44RQYm3Kai+0G6JBFtGP0g+mp1+GEGnNY8dr1 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b098f22e-3256-4076-1bf7-08d786330361 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2019 16:29:55.3954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wDotFSr1EVy6BTqVxX3bNaR9IlBCEfvYTdZwPzlTIXFyGichPAW/k7gSYCdRv1keFhUv+yiekmelODNfCkV1uQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1931 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: [v6ops] Let's use 6MAN + ATN for the documents about IPv6 for the plane industry X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 16:30:01 -0000 IEFmdGVyIGRpc2N1c3Npb25zIHdpdGggdGhlIDZNQU4gYW5kIFY2T1BTIGNoYWlycywgbGV0J3Mg bW92ZSBhbGwgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byB0aGUgSVB2NiBjb21tdW5pY2F0aW9uIGJl dHdlZW4gcGxhbmVzIGFuZC9vciBncm91bmQgdG8gaGFwcGVuIG9uIDZNQU4gKGZvciB0aGUgc3Bl Y2lmaWMgcHJvdG9jb2wgY2hhbmdlcyksIGtlZXBpbmcgQVROQGlldGYub3JnIGluIGNvcHkgaWYg cG9zc2libGUuDQoNClRoZSB1c2UgY2FzZSBpdHNlbGYgc2hvdWxkIGNvbnRpbnVlIHRvIGJlIHBh cnQgb2YgdGhlIGF0bkBpZXRmLm9yZyBtYWlsaW5nIGxpc3QuDQoNCklmIGV2ZXJ5b25lIGZvbGxv d3MgdGhlIGFib3ZlIGd1aWRlbGluZSwgdGhlbiB3ZSBjYW4ga2VlcCB0aGUgZm9jdXMuDQoNCkhh cHB5IFdpbnRlciBIb2xpZGF5cyAoZm9yIHVzIGluIHRoZSBOb3J0aCBoZW1pc3BoZXJlKQ0KDQot w6lyaWMgDQoNCg== From nobody Tue Dec 24 13:05:05 2019 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611CA120059; Tue, 24 Dec 2019 13:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 header.b=RfQowLRj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bXMWWGqI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XacHGcOEM6bQ; Tue, 24 Dec 2019 13:04:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11717120046; Tue, 24 Dec 2019 13:04:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12675; q=dns/txt; s=iport; t=1577221495; x=1578431095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Yanv42pNRPORWy4T60AIknQYiE9vcvV45/zaaYLnd1E=; b=RfQowLRjRj1dp5dECm8uZ0DEl7ZO5o6I5vTAcGXH2ifzdLb7UJB/cEhS ae8xtDun4btafrVSAsNjsUMKFUgFt27BRSpFk5CAtk8CBTTcP1Rh1MAjg 1+5U2/DDT6CuPk7kjk3Pesz9u/pbWoCD78yiRGJY5W2HGdwx/11bibROd c=; IronPort-PHdr: =?us-ascii?q?9a23=3AKBYY1x11JttFXWrRsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAABNfAJe/5hdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWgHAQELAYEiL1AFbFggBAsqCodEA4Rahh2CX5MnhGGBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBIwoCAQGEQAKCHyQ0CQ4CAw0BAQQBAQECAQUEbYU3AQuFXgEBAQE?= =?us-ascii?q?DEgsQEwEBLAsBDwIBCBEEAQEvMh0IAQEEDgUIGoMBgXlNAy4BAgyhRAKBOIh?= =?us-ascii?q?hgieCfgEBBYFJQYJ0GIIMAwaBNgGFHIZ8GoIAgViCTD6BBIFgAgMBgWErgxW?= =?us-ascii?q?CLI1SiD+JYY8iCoI0hk1mjwGCRod7kBaEQYkiC2SIUpIEAgQCBAUCDgEBBYF?= =?us-ascii?q?SOYFYcBU7gmxQGA2NEoNzhRSFP3SBKI8kAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,353,1571702400"; d="scan'208,217";a="683957628" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Dec 2019 21:04:53 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBOL4rWc007646 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Dec 2019 21:04:53 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 15:04:52 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Dec 2019 15:04:52 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Dec 2019 15:04:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mXa31sxBuUhw5yoPv+8QEKi8UKcdHOBFHcMskbbPi1hE/o+iY6wFI7f3sfznLAFhXTJDOYw6xoD7nHsUHYeiZqv6/pAQsxQXGn45gM3hi+Y7S07ENTCaW/m3GabO849ha1Hd7RagQ/ZoGkbUh1HSHV2rbsbWI06eDO2n3SpvBi5ecv3hyGT0xog/BakT/1IYrab+H3b7xliRkojQr/vtirXF2fNRKZCRK9Qya2WrPnk5TSbR+zB8HkckMNRGinV8yq91KdRLhy+oKkVwrmkFbaTrvNaGPi2BKQmWtJSjVgCiuW2SxXoDemK9t33n0h/OkUFhpbVbwT9h47uNlQMTKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0T09Znvo2ryJRn/LpKvBcazupasPcFIMvqC2PPEzRY=; b=kh+89LiWPq8SCX2d52it2wEtIQ/SYtM0D14U7hMQUEyJ0ftByFIzg+2Jim6DdNJYyd5SqKEkiTS1R4w1634C6N9PghyvKqMWAmBkLZ+9Yh4qooHNss3yFTNlzCUK1RhHfRRFAduxxslxxtehQkmgHBbwgTfwclpOD444ggJTMazAEmlXgJn5Pdan6JBC3z0D1MYMrOpSo/vH7FmYAKz1aBQMVoOWaCaWNADcFT9UfbZtlVLeaDzsTC1GjT8+GnrQ2334Ss6z/6x5JG7bqNLP66XurO4TmzZO9XuhIza8zdhgQdoGbDC1yj2RBVLlrVHJPG2cXKCz5n89TWOx76Jqug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o0T09Znvo2ryJRn/LpKvBcazupasPcFIMvqC2PPEzRY=; b=bXMWWGqIZwFEtK8RV7M1XzOTRZ8ty31h+YO5RG/l/0bufBvnoZCLGn5JBz/pyA8haQvIf8fpTteRn0zsQ2FbtvthJPyTvXTpjW52Qo4aeaXy6r34jNn/l3Rys9hRYBQ15QAuxaVbQf7SW0SNdb6FBxARqN6HVCQOzYCLaXjrKXI= Received: from DM6PR11MB4137.namprd11.prod.outlook.com (20.176.126.158) by DM6PR11MB4425.namprd11.prod.outlook.com (52.132.249.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Tue, 24 Dec 2019 21:04:51 +0000 Received: from DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::997f:5e0b:e1c2:2746]) by DM6PR11MB4137.namprd11.prod.outlook.com ([fe80::997f:5e0b:e1c2:2746%2]) with mapi id 15.20.2559.017; Tue, 24 Dec 2019 21:04:51 +0000 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" CC: V6 Ops List , 6man Chairs <6man-chairs@ietf.org> Thread-Topic: Adoption call for draft-link-dhc-v6only - Respond by Dec 24, 2019 Thread-Index: AdWvbxuIW9dPT86sSFyD8FEn+/E6WQLLg1Lw Date: Tue, 24 Dec 2019 21:04:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 183b1886-f73e-490a-5a10-08d788b4eaec x-ms-traffictypediagnostic: DM6PR11MB4425: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(366004)(51874003)(199004)(189003)(76116006)(66946007)(7696005)(71200400001)(8676002)(66556008)(5660300002)(450100002)(81156014)(478600001)(81166006)(64756008)(66476007)(54906003)(66446008)(4326008)(966005)(6506007)(55016002)(33656002)(9686003)(53546011)(6916009)(26005)(2906002)(186003)(316002)(52536014)(86362001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4425; H:DM6PR11MB4137.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fdtGPQPn/rPKM/UjecHTFotO12CuWSVJhENYBgtZK6+d5oW9Tq5u1EYq6z7d0D3zKAw+Z5XLmJIuzWU2MtKDtmnzvrnvHa2LrBa6Qz7HqKr4paSEFLGMG8w2XEjQNWo0GrXUTRw1u+EBXf5pgLuY1YwJugbPZb4SRQtG9vwADF/XJtjHP7E+5VpwdrJibyiOz5A+nFNOF4Ids8dHUEUXMMdvvLo7scaDeDgbBACuX12jzKLQLh7rn/vac9aP7GQWkCAvMQNZKf9p97iDyBU25zIaDnHIVVeMxQq5hWDY173xjORyCaMJKSkcC0ehEB7m9Ya7LmaHIDFnz/4oirj8W5RZOgHZpnQ6Azf8+hjrW+MdpHiawOXNu0y3CWxHHLSLAE+F39TwvmTpzxPSolYRWKiPX0C5qarFDmOeu41nrBDoZBnwt2yqiGejW0I1jADtA45yINo54sKM7UkeYN1iAy+feY/irpieSZLQj1g82mSdhv5sAB+1LQsRkToErix9jVimFFQCiotDt76aYfyPowiHYceUNvo3P5BmYVWNhpo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB4137FD781F731D74AFCBF87BCF290DM6PR11MB4137namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 183b1886-f73e-490a-5a10-08d788b4eaec X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2019 21:04:51.1214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z/iQN9KX+aYsBYTWt2n5hhe+3TVmCZ4jVT3Hsk0P9iF4qSVbxLt8jD+u3TG+JIwR X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4425 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [v6ops] Adoption call for draft-link-dhc-v6only - Respond by Dec 24, 2019 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 21:04:58 -0000 --_000_DM6PR11MB4137FD781F731D74AFCBF87BCF290DM6PR11MB4137namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The DHC WG will adopt this document. There was good support for it, and no = one opposed the adoption. The authors are requested to published the DHC WG= -00 version of this draft. There has been a lot of discussion on the DHC and V6OPS mailing lists about= this document. Happy Holidays! * Bernie (for DHC WG) From: dhcwg On Behalf Of Bernie Volz (volz) Sent: Tuesday, December 10, 2019 10:36 AM To: dhcwg@ietf.org Subject: [dhcwg] Adoption call for draft-link-dhc-v6only - Respond by Dec 2= 4, 2019 Hello: You no doubt have seen the discussion here on the DHC WG mailing list for t= his draft - https://datatracker.ietf.org/doc/draft-link-dhc-v6only/. There = has also been some discussion on the v6ops and 6man mailing lists regarding= it. This starts the call for Adoption of this document. Please respond by Decem= ber 24, 2019. Our AD supports the DHC WG adopting this work and believes that the DHC WG = is the best place to do this work. Thanks in advance for your consideration of whether the WG should or should= not adopt this document as a work item. * Bernie (for DHC WG) --_000_DM6PR11MB4137FD781F731D74AFCBF87BCF290DM6PR11MB4137namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

The DHC WG will adopt this document. There was go= od support for it, and no one opposed the adoption. The authors are request= ed to published the DHC WG -00 version of this draft.

 

There has been a lot of discussion on the DHC and V6= OPS mailing lists about this document.

 

Happy Holidays!

 

  • Bernie (for DHC WG)

 

From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, December 10, 2019 10:36 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Adoption call for draft-link-dhc-v6only - Respond b= y Dec 24, 2019

 

Hello:

 

You no doubt have seen the discussion here on the DH= C WG mailing list for this draft - https:/= /datatracker.ietf.org/doc/draft-link-dhc-v6only/. There has also been s= ome discussion on the v6ops and 6man mailing lists regarding it.=

 

This starts the call for Adoption of this document. = Please respond by December 24, 2019.

 

Our AD supports the DHC WG adopting this work and be= lieves that the DHC WG is the best place to do this work.

 

Thanks in advance for your consideration of whether = the WG should or should not adopt this document as a work item.<= /p>

 

  • Bernie (for DHC WG)
--_000_DM6PR11MB4137FD781F731D74AFCBF87BCF290DM6PR11MB4137namp_--